Support for Multi Developer Account about andlytics HOT 46 CLOSED

yep ^^ and the translation is missing

from andlytics.

I didn't get the problem?! What isn't working? If you actually have a developer account on Play you cannot use it for another console?! After logging in Play asked me which console I would like to go to?!...

from andlytics.

Yes, we just can't use Andlytics :)

from andlytics.

not sure if you need an developer account...
We might each have to register another Google account which is not connected to Google Play in any way and then I invite you guys. This should work I guess...still we would have to try this...

from andlytics.

Or we could add another screen after the first account selection with a list of available consoles (if more than 1).

from andlytics.

I hardcoded my davacc-id @ DeveloperConsole.java, line 574. Now i get a xsrf-token error. Should be possible

from andlytics.

Maybe we could get all apps from all accounts. But then we have to do multiple requests with /?dev_acc=$

from andlytics.

I think the sync is already too slow... waiting for a double (or more) time would be a pain :-/

We can add an option screen, just like the "hide app" screen, to turn off the sync for one or more consoles.

from andlytics.

I think Bruno's idea with the new screen to choose from a list of available consoles sounds like a plan. It is not the best solution but looking at the sync performance it might still be the best option so far.

from andlytics.

If you have you have 2 consoles, one with your own apps and Andlytics. Don't you thunk it's annoying to switch all the time betwen them?

from andlytics.

Yes, indeed. My idea is to replicate the functionality that you can reach by pressing the "select apps to hide" button. We can call it "select consoles to hide" or something like that.

By default (on the first access) all the consoles are unselected and all the apps are displayed togheter on the main screen (with multiple http calls)... but the user can switch on one or more consoles to speed up the sync and hide the apps from selected consoles.

from andlytics.

Kinda, yes. From my point of view it's okay, in case we implement it in the way the ICS mail app does it. Switching between mail accounts and a combined view.
In the ICS mail app you can trigger the sync but just for single accounts, not on the combined view. Would still be okay for me. In case we can speed up the sync we could then add the sync in the combined view.

from andlytics.

Another idea:
Show in "apps to hide" all apps with acount (if multiple), like
appA, consoleA
appB, consoleB
appC, consoleB
appD, consoleB
If you select apps from both consoles, you have to wait for longer

Btw, have you really to wait longer???

1. you have to call https://play.google.com/apps/publish/Home?asp=1
   there you get the "dev_acc" hash for each console (if multiple)
2. then you get for every console https://play.google.com/apps/publish/Home?dev_acc=[HASH] for the app's package names
3. for each package name get stats

So only 2) has to requested twice

from andlytics.

Well, we can try. We are not supposed to release "the perfect app" immediately.

Do some benchmarking now could be difficult because we are too few to be a good sample, so we could try to ask the people out there, hopefully someone with many consoles.

The idea by @fda77 seems ok, this way we could reuse the existing screen and don't have to add another one.

from andlytics.

I get messages like
06-25 17:28:01.553: I/global(5175): Loaded time zone names for en_US in 997ms.
or even
06-25 21:31:52.381: I/global(15295): Loaded time zone names for en_US in 3692ms.
if i sync. Seems to consume much time

from andlytics.

Maybe we should wait for the "Major Developer Console Change ahead" #67

from andlytics.

Can someone with a multi developer account collect some info on how v2 deals with it please.

from andlytics.

I've modified the code contributed to the linked-accounts branch to save the developer ID in the AppInfo table. WIP, but it works. See #347

The real key to a set of applications is the developer ID, so we should be filtering by that when showing in the UI. We'have to figure out a nice way of representing this in the UI, maybe gmail account/dev ID or if possible get the console name(?) somehow to make is similar to what the Web console does (it has a drop down at the top).

Also some DB migration is necessary in order to set the dev ID for all the existing entries in AppInfo. Right now, if you use this on a DB that already has some data it will probably crash and burn.

from andlytics.

We should be able to get the console name, seeing as the Web app can. We can then add that to the list navigation (one dev I'd gives you one entry with just email, multiple dev ids for an email gives you multiple entries showing console name and email on second line.

For the db migration, that is a slight pain as we won't have the dev id at upgrade time, I guess insert a placeholder id (or null), then override with the first dev id in the response on the first check.

from andlytics.

Can't get the time to work on a proper UI for this, but it sort of works and there are a few other features we integrated, so how about we release it as 'experimental support', along with the other new stuff? Maybe some time next week? A few strings may need to be translated, but other than that current dev works OK, at least for me.

from andlytics.

I've just got back from abroad so should finally be able to put in a bit of time over the next week to look at the changes and what can be done, so yes let's aim for end of next week?

from andlytics.

Sure. It's also been said that the Play Store will get an updated on the 15th (when they disable the old console), so this might break a few things.

from andlytics.

Sounds good! I have also been away for the last two weeks and just came back couple hours ago. Will check out the dev branch around Monday / Tuesday :)

from andlytics.

@nelenkov and @willlunniss should we update the changelog already to get it out for translations?

Probably make it a 2.5.0 since Andlytics now supports multi-linked accounts (beta) and the app info?

from andlytics.

2.5 sounds good.

from andlytics.

Probably need to open a new issue for this, but we need to pull latest ABS. They even did a release for us :)

from andlytics.

Updated to 4.3.0 (and manually updated the compatibility lib...) and added some of the translations which are already done... see #403

from andlytics.

Open Translations are Turkish and Italian. I gave the guys a ping and we might get Polish in time too :)

After the release I will move the translations from GL to crowdin since my feeling is that the system is way better to use especially with text files which will make it easier for translators regarding the changelog ans the description.

from andlytics.

Only missing translations are Turkish and Italian, Polish is commited to dev (#404).

Turkish translations will take until next week though...

from andlytics.

Seems that the console update (tablet screnshots, etc.) didn't break anything, we can release this week or wait for Turkish and do it next week.

from andlytics.

We are also lacking Italian which might get done today.

from andlytics.

Releasing this week or next week is both fine with me but I will be offline next week Mon-Wed but that shouldn't be a problem.

from andlytics.

Italian translation done! 👍

from andlytics.

@brunomendola thanks a lot 👍

from andlytics.

@nelenkov @willlunniss I added the last missing translations to the dev branch and will now be mostly offline. So if one of you feels like releasing 2.5.0 feel free to do so. You just have to increment the versionCode anything else should already be updated to 2.5.0.

I'll be fully online again on Thursday next week.

from andlytics.

I will look at it later today or tonight and if there is nothing critical, publish a release.

from andlytics.

I thought I would have some free time but ended up being busy and its probably going to be another week or two now. The latest good seems good, so yes go for a release.

from andlytics.

OK, will try to push it tonight.

from andlytics.

Pushed to Play Store a few minutes ago, should show up soon. Hopefully it won't crash and burn right away :)
Needs more work, so leaving open.

from andlytics.

I don't quite consider this done in the current state, maybe we should leave it open.

from andlytics.

@nelenkov I know ;) The question is how we want to handle tickets: leave them open until we consider it done,done or close it and open new tickets for issues found after we released a feature.

Any opinions? @nelenkov @willlunniss

I am fine with reopening it though

from andlytics.

For features, closed should mean done. Bugs and improvements go into new tickets, of course. For a large feature, the usual idea is to split tickets into more manageable chunks (different opinions on how large 'chunks' should be though). Since this is not done, we need to open more tickets for it. 'Improve UI', 'Support filtering', 'Refactor DB' (for example).

from andlytics.

reopened it 😄

I get your point with the features / sub-features, unfortunately I haven't found a way to use Githubs tracker like that :(

from andlytics.

We can kind of achive sub-features by using tasks (see edited issue description)

from andlytics.

This is neat, didn't know about it. Now we just have to use it :)

from andlytics.

That is neat :) Didn't know about that eather :-)

from andlytics.