Getting the "beta" checkbox took time - that's why the whole "do not approve" thing was used.
What I tend to do is just send side loads if I want someone to try/help debug something. If something like a specific setting or API key is needed, I'll include a .set file (created in the sim) with that info. It's a bit harder to install for some users, but has the advantage that you can send a sideload with debug symbols, and get a much better stack trace if something goes wrong. Also, the sideloads have a fixed name, so if you want the user to create a logs/<myapp>.txt to catch things like println() calls, they don't have to figure out what the store named your .prg
That is what I do as well Jim, just this new Beta setup will make this so much easier. (My main "Beta" tester is my wife. If she does not get to be the first person to use anything I write....(well, you can guess the rest). Not having to take her watch and connect it to my computer would be nice.
Just to clarify that this is just "Phase 1" of the beta testing implementation plan, and only the developer can download a Beta version of his/her app?
That's correct. We've actually had the beta feature on the store for a while now, but I didn't think it was urgent to push developers into using it in the short term. I'd like to get people using it now, though, especially now that we have the 2.4.0 beta out and I expect people will do more experimentation once 2.4.1 is available. There are plans to build out the beta functionality on the store, but I don't have details to share about that today.
I want to test a fairly extensive "Settings" feature in my development app, but want to keep it hidden from the general public until I have completed testing. I have read the Developer Blog about the "beta apps" feature of the Connect IQ app store, but it seems that such apps will be available for the general public.
The "DO NOT APPROVE", feature would have done the trick, has been deprecated and that apps so marked will be rejected.
Distributing the .set file with the .prg as suggested will indeed test the settings feature within the app, but it will not enable me to review and interact with the Settings feature of my app in GCM.
Brandon.ConnectIQ mentioned the possibility of a Phase 2 which would also do the trick.
- to create a new account and share that email address and password with your testers
- upload your beta app to this new account as a beta app
- have all testers disconnect their device from their real garmin connect account and reregister the device with this new account
- have testers login with the new account and download the beta app
A problem with this aproach is that obvisiouly all activities done with those devices registered on the new account will also be uploaded to that account
Are you saying that an app uploaded as beta is only available to the account that uploaded it? That sounds more like alpha testing - which is exactly what I want. I want to alpha test the Settings page in GCM!
But reading the posts, it would appear that an app uploaded as beta is available to everyone: it just has a Beta version label applied by the App Store, so your approach wouldn't apply, wouldd it?
Beta apps will be in “preview mode” forever. The only difference between a beta app and a normal app is that the former never gets approved, even though the store misleadingly shows you the same “up to 3 days” message in both cases. Both types of apps are available for download by the developer immediately, as noted by the “only visible to your account” part of the text.
But the whole reason I’m doing this is to test the user interaction with Settings in GCM. Side loading the app does not implement the Settings option in GCM.
