how to easily test a billing app with Google Play developer console? - javafx-8

Why this question?
I read many articles in "Google Play Developer Console" site (GPDC) but I don't understand how to completely test by myself an in-app billing requesting the Google Play server, before I submit it to testers:
I already got a licence key from Google Play. That points out that my apk file is correctly signed and that GPDC has already checked that.
My product is a one-time product. So, it would be useful, before testing it with the GPDC server, that I provide an item related to this "one-time product" to GPDC, isn't it? I don't read any info about that in the GPDC help.
Moreover, I have included the in-app billing library in my JavaFX code and I want to test it by myself (not by testers). So, the internal, alpha or production tests seem to be inapppropriate. In theses conditions, how to prepare an end-to-end test (I have already included the purchase mechanism). Then, how to test it by myself with GPDC server?
My development context is : JavaFX, Gluon Charm Down and its Gluonhq InAppBilling Service - Eclipse environment
Thanks in advance
Note: is it possible to use the GPDC "Instant app internal test" and include only my email/name in the tester list? In this case, can I test my app loaded in my phone and then make some requests to the GPDC server?

Android docs actually covers this in Test Google Play Billing.
You do not need to list the reserved products in your application's
product list. Google Play already knows about the reserved product
IDs. Also, you do not need to upload your application to the Play
Console to perform static response tests with the reserved product
IDs. You can simply install your application on a device, log into the
device, and make billing requests using the reserved product IDs.

Related

Share an Ionic Framework app with users for testing on real devices

I have made an Ionic Framework 4 app and have tested on my laptop and own phone using localhost but now want to get a few users to test it on their devices. I don't want to put it on any app stores as it's for my uni final project so isn't good enough for that. From what I have read there is no way to test on iOS devices without uploading to the App Store, but I have read testing on Android is easier.
Please could you advise me on how to go about deploying the app for users to test?
Thanks!
I can see some discussion in the comments above about just sideloading this.
That's a good, simple option, but it does require your testers to reduce their security settings to allow loading of apps from non-Google sources.
This depends on your users if this is a responsible thing to ask them. If you are dealing with technically minded people this is ok, but if it's for casual users you need to be sure that you revert this setting afterwards, otherwise they could fall prey to a phishing scam in the future because of what you have asked them to do.
If you do choose to do it via the Google Play app store then you have options for distributing to a select group of people without ever putting it live in the public app store.
Its a $25 lifetime fee to join the app store. Then you can release on the internal testing track for up to 100 users. You just invite them via email, they enroll in your testing channel, and then they can install it safely via the app store.

deployment without physical access to device

I'm wondering if there is a way to show my App to customer before sending it to store.
(and if there is a way to unlock phone to deploy the app into remotely - but officially, nothing illegal).
I need to show "work in progress" to customer who can't visit me and I can't visit him. I have Develoepr Acc and he has some Windows Device he can test it on, but I don't know how to get the app to him before I submit it to store.
Yes you can.
Check this out http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402565(v=vs.105).aspx
You can send the XAP of your project to your customer and he can deploy it on a developer unlocked device using the XAP Deployment Tool of Microsoft SDK. You can find your XAP in the Bin/Release folder of your project. Make sure you deploy your project on Release before you send it to your customer or upload on the store. Check this link you'll find out how to go about it.
Another method that is probably more applicable in many situations is to release a beta version of your app to the store. You'll be able to specify who can install it and you're required to email them a link to the app. The app is not available to the general public and will only work for 90 days from the time you publish it.
This method is more work for you but it lets you give the app to potentially thousands of users and doesn't require that they have a developer/unlocked device.
See this MSDN article for a how-to on releasing a beta application.

Company App distribution without Company Hub app

We have developed a private WP8 application, and we have registered company account on Windows Phone Dev Center.
The next step is the development of "Company Hub app" which will take care for installation and available updates.
Since we have only one application, I think there is no need to develop "Company Hub app".
Is it possible that the application itself check for any available updates? (We plan to develop webservice for upgrades distribution).
Can I do the following:
Application Check for updates
If so, take the installation of a new version
The application installs a new version of itself. (If this is possible, how to do it?)
So far I have managed to find only examples with "Company Hub app"
Thanks
Selvir K
So far I have managed to find only examples with "Company Hub app"
That's because it's the only way.
To deploy applications on Windows Phone, you have three options:
Using the marketplace
Using the company hub: you get the benefits of the marketplace, but inside of your company network
Using the XAP deploy tool. The phone needs to be developer unlocked (it's a free operation now), there is a limit to the number of apps you can deploy this way on a phone, and you lose the benefits of automatic updates
One alternative way could be to publish an app on the marketplace and mark it as hidden. Only people who have the direct link to your app will be able to download it. Still, if the link to the app is somehow leaked outside of the company, you'll have no way to control who installs the app. So don't do that for critical/confidential applications.
I am in the exact same boat. We are working on our fist wp8 app and do not want a company hub.
I found if you use InstallationManager.AddPackageAsync(String, Uri) method within your app this will go to our website and download\install the xap file very easily. Of course once executed it appears to close your app so it can reinstall but for now this works fine for us.
I happened to see this post as I just finished developing a Windows Phone 8 app for a client, which was in a similar situation. I found publishing to Windows Phone Beta Store severed them the best for the moment for the main reasons below.
The distribution is totally in client's control. The apps in beta
store do not appear nor can be searched in public store. Client just need to send
emails with the app link to its employees. Only the people with the
Windows Accounts added into the tester's list are allowed to download
and install it. Up to 10,000 testers are allowed which is more than
enough for most of the business.
It is much easier to publish it in beta store compared to it is in the
public one. It does not require strict certification as it does in public store. It is an automatic process and only takes a few hours compared to up to two weeks in public store.
From the end users point of view, after it is installed there is no difference. It is the same app and it does not expire (as of today).

Building IOS applications and charging the seller without using IAP

This might be a repeated question but I have not find the answer yet
suppose that i want to develop a new ios application that might be used with our customers to collect data concerning them.(for example take orders from outlets, survey data, make a a field inspection...etc)
the application uses a backend application server (developed by us) to login and download lookups data for the IPhone application (such as list of outlets, type of questions...etc). these data are specified previously by our customers though a web application.
my question is, will apple charges our customer of using such service? supposing that the ios application is free and published into apple store?
the application may have a trail account for use by other customers
regards,
Apple won't charge your customers for anything you don't charge them for in your application. If you sell items via IAP, they get a cut. If your iOS app is free and uses a service the user is paying for, that's fine. There are numerous examples of applications that connect to paid-for applications like Basecamp, FreshBooks, Harvest, GitHub, Evernote, and Netflix.

How to restrict application distribution to a group of users only via Apple AppStore?

I'm a first time iPhone application developer and I'm developing application for my client who wish to distribute this application to a group of people related to his business only, and as FREE application only. This is such an application which is not meant for general users so we definitely don't want this application is publicly listed in Apple AppStore, rather we want to distribute application to group of people privately. Just like sending them a link to download application via email or something. They click on it and application get downloaded. But in Apple I read that two programs are available like Standard Program and Enterprise Program. The standard one will list application publicly which we do not want, and enterprise programs looks compelling for enterprise users connected to MS Exchange server which we do not posses and not even wish to setup because its not needed.
Can any one help me answer following?
1. If we go with Standard program, how can we restrict application to be visible via some AppStore link ONLY and we will send that link to our users via email.
2. If we go with Enterprise Program, can we do a simple setup over our Apache+PHP+Linux environment i.e. without involving MS Exchange server.
Thanks,
Sameer.
One way around this is to submit your application to the App Store, but put it's availability date in the future.
Then, you can create promo codes and send them to the people you'd like to be able to download your application, but it won't show up in the store.
If you do it this way, you don't need to know anybody's UDID, but you're limited to 50 people per version of your application.
If we go with Standard program, how can we restrict application to be
visible via some AppStore link ONLY
and we will send that link to our
users via email.
It is very simple: You can not. You can either manually distribute the App through AdHoc distribution (for this you will need the UDID of every single iPhone the app will be installed and afaik the the license runs out every year and needs to be renewed) or post it to the AppStore publicly but restrict access to your application by using an authentication within the App itself.
If we go with Enterprise Program, can we do a simple setup over our
Apache+PHP+Linux environment i.e.
without involving MS Exchange server.
Afaik I think this should be possible as you basically are just doing a huge AdHoc distribution, but without Exchange Server it might get a pain as you will probably also need the UDID. Yet honestly I never took any closer look at this program.
You can setup the app to require a password or hot corner when first run.
The Enterprise Program is your only viable option for a native iPhone App. Re-read the program details. It's exactly what you want.
If you deploy your App as a Web-App, you can skip this and simply deploy on the company website, so if you don't need native iPhone options, this might also be a viable way to deploy your program.
-t
You will need to qualify for the Enterprise Program: you'll need a minimum number of employees and a DUNS number. Read the Enrollment document for more information. Your situation (as described) does not sound like it qualifies.