The last time I used Gerrit (several years ago, might have been in the context of Android), I remember that it was only possible to submit changes in different repositories with the same topic at the same time. A quick Internet search for "Gerrit submit whole topic" seems to confirm this. But now, with version 3.7.0, when I approve one change with a given topic, while other changes with the same topic are not yet approved, I am still able to submit that change. Furthermore, when all changes with a topic are approved, no "submit whole topic" button appears in the UI as it used to.
When did this change? What is now the correct way to force changes across several repositories to be submitted together?
Related
The documentation states on a topic when to ask for a review:
Trigger the in-app review flow after a user has experienced enough of
your app or game to provide useful feedback.
Do not prompt the user excessively for a review. This approach helps
minimize user frustration and limit API usage (see the section on
quotas).
But that's very vague, can we trigger it quite often (like after every level in a game) or should we add some wait periods inside the app (like after every level but minimum wait time a month)?
There is a similar API on iOS and it's observed that the popup shows "about three times a year". It would be helpful to know similar rough estimate, it would help to design right usage of the API and remove unnecessary user frustration.
There is no response as to whether the user rated your app or the rating dialog was shown through the In-App Review API itself. But you get these guarantees:
If the app already has been reviewed by a user, they won't be prompted to review the app again.
You can test without quota by testing against Internal App Sharing or the Internal Test Track.
In case you are concerned that you might display the dialog too often, we recommend remembering when you last called launchReviewFlow locally in a persistent way.
Let's go with your example of calling launchReviewFlow after every level:
Depending on the size of a level this might be too much
You won't know whether the dialog has been displayed
Once the user rates your app the dialog won't show again
Source
I have developed an android "Group Chat" app. Me and 20 of my friends are using this app to group chat with each other. When I look at the firebase database, I obviously see 21 users (including myself). However, I can't know whether all of them actually have the app installed on their phones, or some of them have uninstalled it. Is there any way I can differentiate among my uses? Generally speaking, can I "flag" my users as, say, active, inactive, and the like?
What is if you add a timestamp every time a use log in. With this timestamp you can see how long the user not log in and so if he is in active for a long time or not. It's not say if the user have delete the app. It's only a prognosis.
If i understand correctly your question, it can be split in two parts.
First part is whether you want to know if your users are online or offline this could be achieved by an online presence system as described here
The second part is whether or not users have installed or uninstalled your app.
In my opinion easiest way to do this is by using the Firebase Analytics SDK. This way you can check the app_remove stats and whenever a user uninstalls an app, it gets updated in the console under events section.
This will give you how many devices uninstalled the app and some info on country, gender and age of the user but you could couple this with a "last login" timestamp to pinpoint the exact user.
More details along with how to include analytics SDK to your app can be found here
Or you can use the .info/connected to have this functionality in your client code. You can read more info about this here and the sample presence app at the bottom of the page will help you get a grip on how to do it.
One possible solution is to add a flag in the database as the child of the user. This flag will have an initial value of active.
And instead of uninstalling the app directly, you can have a delete account functionality in the app, and whenever someone wants to delete his/her account, it simply updates the flag to inactive in firebase database.
Now you will know actually who is active / inactive.
This is a repeated question as i have not got answer . Hope someone will look at this and answer .
I have an android application which has number of downloads . I want to update the app with some major fixes and updates . Because of this update, end user may get failed authentication and need to reenter his credentials which I dont like. At the same time i want keep same package name to keep downloads and app reputation on playstore.
So how can i achive these
1.update android app on playstore which will not push automatic updates even if end user turn-on autoupdate in settings .
Previous app downloads and userfeedback should be there
So this way old users still continue using old version and any new users who download app from playstore will enjoy new app .
Thank you
Ok, you mentioned keeping a package name and stuff... Changing that should never be an option. The user could have ten of the same app, all with different features because your updates are all packaged separately. There isn't really a way to stop Google Play from auto updating apps, the users may just have to deal with reentering credentials. Since there isn't a way around this, you could simply apologize to the user. Example:
When the user logs in, save a boolean called something like, "wasLoggedIn". Then, on your login/startup page check if that is true. If it is, display a dialog such as, "Sorry for the inconvenience, you have been logged out due to an error." This will make the user a little more comfortable logging in again.
I'm using Google's in-app billing V3 to get orders processed in my Android app. I've been testing the system by uploading my APK to beta and listing my email as a test account so that I could go back and forth without being charged anything. These orders all remained (in Google Wallet) as "pending" (i.e., yellow circle). Then, about 1 month after I charged myself, the orders began being automatically canceled by Google. I figured this was because they were all tests.
Recently, I upgraded the APK to published status and got my first real order. Strangely enough, it's still "pending" (no green circle here). This got me to thinking that maybe all the other previous pending orders were actually mistakes. Can anyone confirm this? How do I find out what I did wrong? Or, am I just being a little too rushed and real orders take a long time to process?
The way my system is set up is that as the user pays, I send them the product via email. Does this, in some way, make the transaction not go through? I guess I don't really understand how it all works in the background. Any clarification here would be greatly appreciated.
This is for anyone who may run into this problem in the future:
After speaking with a Google representative, the short story is that you just have to wait.
Initially, the same representative informed me that, even with test/beta orders, the transactions would process (just not charged). Because of this, I was under the impression that my code was buggy.
Turns out, beta orders are never processed and remain as "pending" for their entire lifetime (which is a couple of weeks). Real orders, on the other hand, could take 6+ hours to process.
In regards to how the product is delivered, that did not play into the processing equation at all.
Hiho,
is there a solution to disable my App for one single user?
There is one Person, who buys my app every few days to use the app for calculations, and than deinstalls the app within the 15 Minuts window.
Over 10 times he did it and with the next update i want to create a method, that checks the user mail from market and if its these person, the App should close instantly.
Thanks for Help
Alex
Are you sure this is the same user (and not just a usage trend of one refund every few days)? A user should only be able to refund an app once. According to the App Refund article in Android Market Support:
You have 15 minutes from the time of download to return an application purchased through Android Market for a full refund. You may only return a given application once; if you subsequently purchase the same app again, you may not return it a second time.
EDIT: If it looks like it's the same user, please contact Android Market Support and let them know. Follow the relevant "Contact Us" link at the bottom, and include all relevant information: App name, user's email address, order ID's, etc. Abusing the refund policy like this shouldn't be possible. If it is, they need to know so that hole can be closed :)
you can get the accounts from accountmanager, as I know to do what you want, checking account is the only way I think. you will need GET_ACCOUNTS permission.
Instead of putting in hate code for this single user, I'd suggest you put in a little more effort and put in a more generic check.
Whenever a user signs up, check if the user has already used your application, and if he/she has not, save the user's account information on a backend. Else notify him saying that he/she has already checked the application out and if he/she has some feedback. Try to make the user 'guilty' here!
Building a backend system is pretty simple with a service like stackmob.com. Though for this, you'll need to acquire the GET_ACCOUNTS permission, and for a service like calculator, asking for this permission might seem fishy. So you need to make that call here!
If you do figure out how to identify your user rather than close right away you should do stuff that delays them for 15 minutes.
Make them fill out some forms first (Just for that user), stuff that takes time. Be really specific in the forms with password requirements like 10 chars including upper, lower number and punctuation, then force them to "Log in" using this password (which they won't remember and will have to start over...), but always make it look like each step is the "Last little bit" they will have to do before they can use the app...
Also use a lot of "Contacting server..." and "Calculating" and "Installing" that take time. If you really need to stretch it out, add a few "Retrying" after the connecting message has been there for a while.