Peter, PAD support is on the list of things to do, but as you've mentioned it's not a trivial thing due to it's not android aware at the moment. What I'll probably do is be a bit lenient on the implementation and allow .apks for the download urls.
Any reason you're not using "Handheld/Mobile" in the OS field?, I'm not familiar with PAD Gen, but the PAD spec supports it. Al. blindfold wrote: > Hi Shane and Al, > > Will you be adding support for PADGen ( > http://www.asp-shareware.org/pad/padgen.php > ) or some equivalent? As a developer I can live with manual release > updates on a very small number of selected distributor sites for a > short while, but after that I must rely on PAD file polling to have my > updates ripple through the web in order to limit maintenance and > distribution drag. I use this also for my J2ME and Microsoft Windows > distributions. > > I'm already using a PAD file for my Android app even though it does > not quite match formats (e.g., Android is not even mentioned among the > selectable OS's in PADGen, so I pick Java, and I have to specify a zip > file instead of an apk file). > > Thanks, > > Peter > > > The vOICe Android for Android Phones > http://www.seeingwithsound.com/android.htm > > > On Oct 14, 10:52 am, "Shane Isbell" <[EMAIL PROTECTED]> wrote: > >> The models are a bit different here between SlideME and AndAppStore. Just >> due to pure economics, at SlideME we are going to have to do some testing on >> the paid applications before they are published, the refund and chargeback >> costs being too high for us to eat on a bad app. When it comes to dollars >> out of my pocket, I have to agree with hackbod about device testing (weird, >> me agreeing with Google on something). >> >> But if it's an unpaid app, anything goes; if they are crappy, they will >> eventually get one star and either nobody will be able to find them or the >> comments alone will scare away others from doing further downloads. If they >> are good, they will get a lot of downloads, device tested or not. At >> SlideME, we associate the apps closely with the developer, so if they have a >> history of good apps, people will likely buy more of their apps, but with a >> history of bad untested apps, their reputation suffers. So there is an >> incentive to have good quality apps and to seek out testers on actual >> devices. >> >> Even for those inside of carriers and their favored vendors, getting test >> devices is a big pain so providing third-party devs with devices seems >> unlikely to me. As I have proposed on the list before, we need to get a >> group of guys with devices willing to volunteer some time and test apps. I'm >> pretty sure that with enough community participation, we can get better >> coverage than the carriers and aggregators on testing. >> >> As for there being mutliple devices, in the early days of J2ME, there was an >> idea to have 10,000 apps in a portal and to do device capability to content >> requirement matching. Carriers were a bit paranoid and squashed this idea >> pretty quickly (I think a little too quickly) and began hardcoding apps to >> device ids. This practice filtered over to more than a few big aggregators. >> The maintence costs on this are a killer and I think people got stuck in >> this box. The problem is there is no way to have an open system, with tens >> of thousands of apps tested on every device. This is where ratings and >> comments become crucial to getting high quality apps. >> >> Shane >> > > > > -- Al Sutton W: www.alsutton.com B: alsutton.wordpress.com T: twitter.com/alsutton --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
