Looking For Help On Project

[milkshake]

Hi, Ive been wanting to help make a native app for downloading pnd's to the pandora.

Im no good at programming for pandora though, what I want to do is create a website using php and mysql (maybe even some ajax for the website side fo things). I also want to create some specific php pages that can be called directly from a native app so that the php page just generates an array that can be read and processed by the native app, that way it uses less bandwith than a webpage and would load quicker etc.

I know this is supposed to happen eventually anyway but as of yet it hasnt so... does this sound plausable? and would anyone wanna join the project on the native app side of the programming? ill do the web side of things, could be a nice little project let me know what you guys think.

obviously the end result would have things like login's it would know if any apps need updating on ur pandora etc it would just be awsome.

****************************************
*array would contain details such as...*
array(appid,appname,filename(would be changed apon download),details,imageurl,downloads,rating)

all the tables etc would be built in the native app and populated with the info in the array.
on first load array would be cached locally and dated or marked so it could be compared next time the app is run to check for new/updated apps.

the array should be quite small even if has lots of entried and onced cached would load really quickly, also images could be precached if wanted although that might take a while to download, might as well only cach those that have been viewed.

logins could be used to store downloaded info or if native app programmer is good enough could just pull all current app names from pnd files on the memory cards and chache for comparison so the app knows what pnd's you already have.

I need to stop typing now getting too excited.

maybe more obviously those were things off top of my head, and the array would be sent as plain text.

 

[Hooka]

There are lots of things to consider with this, like are you just going to store a plain text/XML, etc. of arrays or would you be better off using SQLite for an embedded database for it?

Where are you storing this info, we have NAND (which we should try to avoid using), or two SD cards... optimally you would want to give the user the ability to choose which SD card to install on and would need information about the available programs (aka aforementioned database) on both cards. This would be best that way if you remove one card it still knows what's available on the card.

Another thing that is important to consider is that if you do something like this are you also going to make a Windows/Linux/Mac version also for those people who don't have wireless or prefer to use their desktop to update their software?

These are just a few small things that need to be considered and there is many more. Like who is going to manage the package repository and host it or are you wanting to make this something that uses pandora app store or the archive?

Anyways, I do really support the idea of a package manager for the Pandora and still think it should be called BOX

 

[Chaser]

Not sure how well it works but Bryce Leo already came up with an app for this kind of thing, so perhaps its wise to use this as a building block?

http://www.gp32x.de/board/index.php?/topic/55023-supa-simple-updater-for-pandora-applications/page__p__925534__hl__PND%20updater__fromsearch__1&#entry925534

I havent tried using it (kinda chicken of me, as I usually give most stuff a go) but its supposed to function well already according to the thread above.

edit:
The Box is definitely the name to go with and heres the discussions of Dflemstr's version http://www.gp32x.de/board/index.php?/topic/53676-the-box/ I add these, as I never got around to reading these (as I suspect much of it is way above my head), so ill read it now anyway to get upto speed.

 

[milkshake]

There are lots of things to consider with this, like are you just going to store a plain text/XML, etc. of arrays or would you be better off using SQLite for an embedded database for it?

Where are you storing this info, we have NAND (which we should try to avoid using), or two SD cards... optimally you would want to give the user the ability to choose which SD card to install on and would need information about the available programs (aka aforementioned database) on both cards. This would be best that way if you remove one card it still knows what's available on the card.

Another thing that is important to consider is that if you do something like this are you also going to make a Windows/Linux/Mac version also for those people who don't have wireless or prefer to use their desktop to update their software?

These are just a few small things that need to be considered and there is many more. Like who is going to manage the package repository and host it or are you wanting to make this something that uses pandora app store or the archive?

Anyways, I do really support the idea of a package manager for the Pandora and still think it should be called BOX

Well I would be building the web backend it would use a database but I wouldn't allow direct access to the mysql database that would not be very safe.

The pandora programmers/porters would upload there pnd's to my site (if it works out well and evildragon or craig wants to host it then I would gladly pass on all the files needed to do this) which will build the database.

I will be using php to pull the info from the database and then output this as an array (native C++ array?) or JSON or xml format.

The native app could then just save/cach the output to text or some more appropriate file type locally for fast access to know whats in the app store and build the UI based on the local data.

The native app would check upon launch to see if there was any new apps if so it would re-apply for the data and store/cache the new data.

Of course it would be accessible from a pc because I will be creating a web version which could also be accessed from you pandora if you wanted but why bother as the native app would be better/faster anyway.

Im looking for someone that will code the native app because although I can write php, javascript and html etc when I look at all the different things that go into coding for pandora, it blows my mind!!! developing for the web as far as im concerned is much easier I don't have to compile anything or build a toolchain or any of those things, I just upload my .php files and the server just runs the code and outputs what is needed to the browser, simple

Ideally the native app would check ur memory cards for existing apps and compare them with the ones on the server to see if there were any updates and would tell you there were updates and ask you if you want to download the new version.

For the native app im looking for it to be built with an actual GUI that looks nice (comparible to apples or googles app stores) I could provide any graphics to help make it look nice rather than using the native Linux desktop GUI elements.

I just need help from the community to get the native application built, is there anyone who can help?

 

[Tempel]

I mentioned it in your other thread, but it bears repeating: you would probably be best off using The Box as your backend (source is here). It already does everything you want your backend to do, including producing a repository list that matches the official specification. It also looks to be really well designed.

Granted, it's not PHP and it does require compiling, but the build and install process is well documented. If you want to extend it, you'll obviously have to learn Scala, but since the whole application is already there, it shouldn't be an insurmountable challenge.

If you get The Box deployed and make sure it stays up-to-date with PNDs, that will create a big incentive for someone to create a native frontend. I might even be able to make one myself (though I won't be for now, as I have a thesis to get out of the way first).

 

[milkshake]

I mentioned it in your other thread, but it bears repeating: you would probably be best off using The Box as your backend (source is here). It already does everything you want your backend to do, including producing a repository list that matches the official specification. It also looks to be really well designed.

Granted, it's not PHP and it does require compiling, but the build and install process is well documented. If you want to extend it, you'll obviously have to learn Scala, but since the whole application is already there, it shouldn't be an insurmountable challenge.

If you get The Box deployed and make sure it stays up-to-date with PNDs, that will create a big incentive for someone to create a native frontend. I might even be able to make one myself (though I won't be for now, as I have a thesis to get out of the way first).

I would use the box if it were coded in php because then I could extend the functionality etc if needed, plus im not sure the host I that pay for allows for scala programmed websites.

As much as I love the box and dflemstr (I tried to help him on the box when he was developing it if you check that thread). I can only move forward with what I have some knowledge of wich is php and I will use the pnd repo specifications in the JSON that it will output, if you want to help I would really appreciate it.

 

[Tempel]

I would use the box if it were coded in php because then I could extend the functionality etc if needed, plus im not sure the host I that pay for allows for scala programmed websites.

Well, it's written in Scala, but it compiles into a Java servlet, which is a fairly standard technology. Of course, you can create whatever you want, I'll just be sad to see such a nice piece of work go to waste.

And like I said, I have no time to help with a frontend now, but maybe eventually. I'll let you know if I ever decide to get started on one.

 

[likwidoxigen]

It already does everything you want your backend to do, including producing a repository list that matches the official specification. It also looks to be really well designed.

There is no "Official Specification." That's just a wiki-page that Dflemstr whipped up.
It's not a bad document and if The Box ever goes live compatability would be great.

 

[Tempel]

Are you sure? I see that dflemstr wrote that wiki page, but I swear that the spec was created by skeezix, libpnd's main developer; I have vague memories of him saying so. Regardless, it is a specification that seems to cover everything important and, with no competing sets of specs, it's probably the way to go.

 

[WizardStan]

It's all in "The Box" thread. dflemstr designed the spec with Jeff's blessing and community support. A little while later Jeff officially adopted it as the defacto spec but I can't remember what thread that was in.

 

[likwidoxigen]

It's all in "The Box" thread. dflemstr designed the spec with Jeff's blessing and community support. A little while later Jeff officially adopted it as the defacto spec but I can't remember what thread that was in.

Ok I did some checking and didn't see it get blessed. But duly noted, Thanks for the info WizardStan.

 

[WizardStan]

Ok I did some checking and didn't see it get blessed. But duly noted, Thanks for the info WizardStan.

Well, the blessing was never explicitly given in that thread, but it was heavily implied by the fact that Jeff was working alongside dflemstr and encouraging him with things like "THIS is what it's all about "

 

[likwidoxigen]

Ok I did some checking and didn't see it get blessed. But duly noted, Thanks for the info WizardStan.

Well, the blessing was never explicitly given in that thread, but it was heavily implied by the fact that Jeff was working alongside dflemstr and encouraging him with things like "THIS is what it's all about "

Lol, I hear the blessing is coming officially in 2 months
But I can roll with that.