I am looking to begin using inAppUpdates and publish an app on the Google Play store.
I've read through the documentation, and found it to be lacking at best.
As of now, I have the app published for Internal Testing, and I can get the app to recognize that there is an update and install it. However, it seems that I need to specify that it's either a FLEXIBLE update, or an IMMIDIATE update. I did find that I can use the Play Developer API to set the updatePriority, but the documentation on that is confusing and incomplete.
As I understand it, I need to implement the API, the set the updatePriority value to something between 0 and 5. But nothing on how to actually do that.
By default the AppUpdateInfo returns 0 as the updatePriority.
Since there is no other way to set the priority, and can't seem to find anything how how to implement the API in order to set it, I'm wondering if the API is even necessary. Can I just set a variable to check with each update and do it that way?
For example:
private String UpdateType;
Then when making a update I set UpdateType = "Flex"; or UpdateType = "Immediate";
and run the IMMEDITATE or FLEXIBLE update based on that?
Or should I be using the API, and if so, where can I find some good instructions on how to actually use it?
Related
I'm building an Android app which syncs data to Google Fit and uses the Google Fit SDK to achieve that - but I'm pretty sure my question also applies when you are using the REST API.
Within my app users can also change data inserted to Google Fit. The Google Fit SDK has two distinct functions to handle those kind of things: insertData() and updateData().
Now, I don't want to keep track of whether a user changed an already synced data point vs whether it is an entirely new datapoint. I just want to have a simple Boolean flag which indicates whether a data point has already been uploaded to Google Fit or not - that's to keep things simple and reliable on the app's side.
So when a user creates a new data point in my app, I set a syncedToGoogleFit flag for that data point in my DB to 0. When the data point has been synced to Google Fit I set it to 1. When the user later changes the data point in my app I set it to 0 again and so on.
However, the Google Fit SDK distinguishes between inserting and updating which means a simple Boolean wouldn't be enough to track changes on my end as insertData() will fail if there already is a data point for a given timestamp. Is it possible to always call updateData() even if I am actually inserting new data and that way get by with just the Boolean flag on my end?
Looking at the documentation it should be okay, but I would feel safer if someone could confirm that. Also I'd like to know whether there are any potential performance implications of the approach outlined above, but I guess this is just something the SDK devs can answer.
I've played around quite a bit with the SDK now and from what I am seeing I can say, that using updateData() seems to work just fine.
How Do I implement both flexible and immediate in-app update in app at once and how do i set which type of update i want the user to see.
I found a solution for this problem which I have implemented for my project, I am using an API to send me if I want to give immediate or flexible update and based on that I have used if-else to run the desired code.
It is up to the user to decide which type of UPDATE they want.
It can also be configured via the remote config variable to decide which type of update they want.
It always returns true whether update type is FLEXIBLE or IMMEDIATE
isUpdateTypeAllowed(AppUpdateType.FLEXIBLE)
isUpdateTypeAllowed(AppUpdateType.IMMEDIATE)
I have already integrated in-app update API in Many Mobile Application and It is running all perfect now. The documentation had this ambiguity.
So you should write your own logic whether you want Flexible or Immediate Update via remote config or server.
I am trying to create an experiment using Firebase remote config.
The criteria is as follows:
It should target only new users who have not used the app ( opening the app for the first time)
Now on further research I found that there is a user property as below:
However, this is not available in the experiment window or a similar property that fulfils the above criteria in the Firebase console as seen below:
I can only see the user properties set by my code. One way I can think of is to use one of my custom user property which is not yet set (but set to a value like null), but I don't know how I can do this.
References
https://support.google.com/firebase/answer/6317486?hl=en
https://firebase.googleblog.com/2016/10/better-user-targeting-with-firebase.html
I will share our experience with experiments for new users and how the different combinations of targeting work because we worked with it a lot already. You can skip the investigation part if you're not interested and just check the solution that we use now.
Our Investigations Part:
Firstly, when we integrated Firebase, we were afraid that Audiences won't work properly for experiments targeting cuz all current users will be treated as new ones after integration, so we checked several approaches and went with an approach of creating specific User Properties that we specified on the client side differently for old/new users. For instance, we created a User Property called adv_experiment_enrolled and specified on client side values 'enrolled'/'not_enrolled', so all new users after installation of this version became 'enrolled' and old ones after updating the version just became 'not_enrolled'. And we just used that User Property as targeting in an experiment. That worked well, but it wasn't a general approach that we could use easily for all experiments and we needed to create User Properties for each new experiment.
So we've tried the Audiences approach after few months of integration that was what #jackes described here with First Open Time user property:
https://stackoverflow.com/a/50075684/2723437
And we've got several problems, first of all, seems they had some troubles with populating of that kind of audience and just ~3-5% of new users were getting there. We also created an Audience depending on First Open event itself and used it too, it was populating better and was close to the real number of installs that we had. But we've noticed problems with this approach as well and the biggest one was that an experiment had only 20-30% of users from that Audience. We tested it and noticed by some of our metrics that seems users are not enrolled in this experiment in their first session cuz 1) Firebase takes some time to enroll a user in the Audience and 2) Remote Config has 12h cache by default, so it wasn't really a data for most of the new installations.
A solution that seems to work well for now:
We were surprised with that Firebase does have User Property for First Open Time, but doesn't allow to use this as the targeting for experiments (It would be very helpful to solve this problem tbh), so we just decided to try our good experience with User Property targeting and apply the general approach First Open Time user property, so we've created our own custom_first_open_time especially to target installations after some specific time (we just used current timestamps for platforms in seconds).
Important notes:
- You have to set up user properties before loading a remote config.
- You have to keep this first open time on the client side persistently once you generated it (usually you use NSUserDefaults/SharedPreferences for iOS/Android for that)
Sample of experiment configuration:
Didn't tried, but it should work. Create an Audience in Firebase Console with following condition: First Open Time is greater than or equal to some date. Where the date should be the next day after you starting an experiment.
According to the GPGS website-
Use the client libraries. The mobile client libraries employ a number
of strategies to reduce the calls you make to the service. For
instance, achievement and leaderboard data is cached, so a user can
view their achievements as often as they'd like without requiring the
service to make multiple calls. Both the Android and iOS client
libraries will know not to send a player's score to the server if
your score isn't as good as one you recently submitted. The Android
library also automatically combines frequent achievement increment
calls when it detects that you are being rate limited.
I'm specifically interested in 'viewing achievements without requiring the service to make multiple calls'. As far as I can see, the best way to do this would be to use the OnAchievementsLoadedListener and get a reference to the achievementBuffer.
Will that buffer be updated when an achievement state is changed and is it okay not to close that buffer immediately? If not, the OnAchievementsUpdatedListener does not pass a buffer or even and indiviudal achievement reference so how would I get the updated collection of achievements?
I found my answer here:
https://developer.android.com/reference/com/google/android/gms/games/GamesClient.html#loadAchievements%28com.google.android.gms.games.achievement.OnAchievementsLoadedListener,%20boolean%29
Set forceReload argument to false to gain the advantages of data-caching :)
I'm trying to retrieve the people in a user's circle that have installed the current application.
I have used the sample application "PlusSampleActivity" provided in the SDK and successfully managed to get the list of all people in the user's circles.
However, I'm not sure how to get if the person have installed the application or not. The documentation available seems to be very limited...
What I have found is
https://developer.android.com/reference/com/google/android/gms/plus/model/people/Person.html
I'm using below function but this is always returning false. (I have created a user that have installed the app and I can see this when visiting the user's profile on the web using Google+)
Is there some other API that should be used? Or some way to debug this better?
public abstract boolean isHasApp ()
If "true", indicates that the person has installed the app that is
making the request and has chosen to expose this install state to the
caller. A value of "false" indicates that the install state cannot be
determined (it is either not installed or the person has chosen to
keep this information private).
UPDATED
Seems like the hasapp field is not even included in the response?
When trying the API on below link, I never succeed to have the hasapp included in the response... Any suggestions what I might be doing wrong??
https://developers.google.com/apis-explorer/#p/plus/v1/plus.people.get
(I posted the same question on Google groups, here)
Unfortunately, the hasApp field doesn't get filled in the response - it's actually a legacy field from an older API. The best way of matching is to keep track of installed users in your database with their Google IDs, and compare that to the IDs in the people.list response.
The documentation should be updated to reflect this soon, sorry for the confusion!