I see it always differ from Installed audience and is mostly more. I am curious how this value gets calculated ?
I believe it's quite confusing as it has similar meaning as installed audience while it always differ and more surprisingly is always higher number. I was googling but could not find definition for exactly this anywhere.
Active devices are defined as:
An active device is one that has been turned on at least once in the previous 30 days.
Source: View and understand your app's quality and reach
Installed audience is defined as
The number of users who have your app installed on at least one device that has been turned on in the last 30 days
(Source: Google Play console)
Related
I've never had this issue with the Play Console before. I can see crashes happening in the graph (and some users reported them too), but I do not see any details or stracktraces for them.
How can there be around 40 actual crashes in the past 7 days, but only 3 registered reports in the console in the same time.
My only guess is because I'm using the roll-out feature on 75%, so not all users received it yet and Google is withholding the data until it's fully released? Or is it because literally none of the affected users agreed to crash reports being shared?
I think #Pierre was right with his comment, it seems like after about 2 weeks, I suddenly could see detailed crash reports with stacktraces. But also only for a fraction of all visible crashes in the graph. So I'm still not 100% sure.
Overall it really could to be the case that detailed stacktraces are held back until enough users have been affected. Though in my case, one report showed up with 10 users affected, while another affected only 3. But they showed up on the same day.
So it could also very well be that it's dependent on something else.
Say my developer account is x#y.com. Imagine you have two clients.
It is, in fact, possible to be on two different development teams:
That's precisely what I see when I log in to developer.apple.com member center (i.e., after their recent 24 hour downtime :/ ).
How did I achieve that? I'm trying to do it again with a third client but it seems almost impossible. When I log in as the third company, and try to add "x#y.com", I just get the annoying message
There are many questions about that annoying message, here on SO and elsewhere, but with no resolution. How to achieve the image shown at top? How to add a third one .. for that matter how the heck was the second added?
Darn - the answer here is pretty simple.
The "third company" has to log in on developer.apple.com ...
NOT on AITconnect .. itunesconnect.apple.com
There's then a facility to invite a new member - make them "admin" - who is already an Apple developer. It then works fine - that dev gets an invite email, can then get the certs, and so on.
It's an interesting phenomenon that there are dozens of questions about this on the net, due to the AIT connect confusion: essentially the solution is that simple. Hope it helps someone googling.
Mac OSX has this feature called (I think) 'Services'. It is available in the menu bar under the filename of the application (e.g. Finder) and then selecting 'Services'. This gives you access to a list of applications that provide 'services'. For example, if you are browsing a website with firefox and you have some text selected on the page, the services list has an entry for Mail > send selection.
I've been using a Mac for almost 3 years and I've literally never used it (but I've known it to be there from the beginning).
So, is it worth for an application developer to provide support for this (i.e. provide some services actions)? Or would it be a waste of effort (because no one, or very few people, uses it) ?
I've attempted to use it a few times over the past ten years.
Previously, the menu was cluttered with disabled items, and uselessly disorganized. Actually making a selection was unpredictable, as the few items that weren't disabled were often supposed to be. The appearance of possibly doing something was itself just a bug.
However, it appears to be much improved in 10.6. If you want to provide a universal, context-sensitive service, I'd say go for it. Maybe it will be the killer app for this decade-dormant delivery doodad.
I have used Mac OS X since Developer Preview 2 (and earlier versions of Mac OS before that, though they didn't have the Services menu), and I have never used the Services menu.
I'm sure some people, somewhere must use them occasionally, though I have never seen it. I would say it's likely a waste of effort unless one of your users specifically requests the feature.
I use them from time to time. But other pretty high profile users seem to think they're the dog's bollocks. So I suspect it depends on your audience.
Only you can judge whether there's the remotest chance your users will care, but I certainly wouldn't rule it out. If your software genuinely does provide a service that would be of benefit beyond its own application context, exposing that as a service definitely seems like something worth considering. You wouldn't neglect copy and paste out of hand, would you?
In 10.6 they are a lot more useful (as Potatoswatter indicates, they are properly Contextual in 10.6, so that it only displays text based services, when you have text selected).
For what it's worth - I've rarely used the Services menu at the top, but have sometimes used them via the context menu - but primarily with Apple's own apps (send to iPhoto, open in Preview). There aren't many third party apps that offer services I find useful.
However, I am aware that some users of journaling/clipboarding software swear by them. WalkyTalky has the right view - if your application exposes a service that is useful (or if you think users would want to regularly select and push data into your app) then adding support would be useful.
(In contrast - if it doesn't, then adding one is just adding to the 'noise' - I have a notebook application that adds a service for every single new notebook created).
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Question for indie Mac developers out there:
How do I implement a 30-day time trial in a non-evil fashion? Putting a counter in the prefs is not an option, since wiping prefs once a month is not a problem for an average user. Putting the counter in a hidden file somewhere sounds a bit dodgy - as a user I hate when apps sprinkle my hard drive with random files. Any ideas?
This issue comes up repeatedly on the cocoa-dev mailing list and the consensus answer is always do the simplest thing possible. Determined hackers will break all but the most over-engineered solution. And they're unlikely to pay for the software anyways. Go for the 80/20 solution: the easy solution that gets 80% effect for 20% effort. In this case, putting something in ~/Library/Application Support/your.app.com/. You might name the file something innocent if you want to obfuscate things just a bit. Using the user defaults is easy too.
Whatever you do, don't use the MAC address or an other hardware ID. Users with a network home directory (e.g. in a shared lab setting) will hate you. Using hardware IDs is just evil.
If someone is in love with your program so much that they're willing to break your trial limits, let them. The free software costs you nothing and their good will (and maybe recommendation to others) is worth a lot.
Finally, write software that people want to use and price it for its value. If your price is a good value and people want to use it, most people will pay for it.
I would suggest to implement few of things which are less intrusive and may avoid a normal user to either uninstall or buy at one month period.
Use a special series of trial-serial number which stores expiry date in it. You can use encrpytion to store expiry date within the serial number.
Now create a configuration file which stores data in the encypted format and contain the serial number.
Additionally implement these things in the config file.
Make a note of time/date every time user starts the application.
Note the duration of the time application was open.
By doing the logging of timestamp you can avoid these workarounds:
If user reverses the computer date, you would know that app was already run on that day. Say user ran app on 1 and 3 day of month. Now after 30 days reverses the date and sets it to 2nd of month. Now by config file you would know that app already ran on 1 and 3 so user has messed up dates on the computer.
Let’s say every time user starts your app by first setting date to 5th of the month. By logging your application running time you would see that if the total hours in a day exceed 24 then user is fooling around.
Ensure that your app doesn’t run without the config file. So essentially you send the encrypted serial number in a file or maybe upon entering the serial number you can create file. Since the serial number already has the expiry date user can’t reuse the serial number also.
I would not suggest the internet way because people get pissed off when app tries to connect to server every time. Plus, one may get suspicious that you trying to send some personal data of users to your servers.
One thing I would like to say: No matter how strong the anti-piracy technique you use, someone is bound to break it. You are not making your app for those guys. You are making your app for people who would like your software and will buy it happily. So have the anti-piracy in limits without losing the genuine customers by making your application too intrusive during the trial period. One thought also says, if your software is getting cracked that means it’s getting popular also. Again opinions may differ and would not like to digress on these issues.
Consider this. How many potential users of your software are out there, just itching to use it solidly for the next 30 days?
I suspect the far more normal case is: Users encounter a new software package that solves a problem they've had on a site like lifehacker.com. the software gets downloaded, played with briefly, then put aside. Perhaps its mp3 ripping software and they don't have any cd's to rip at that time. Or they're just busy that day, but they'll get round to reviewing that software 'soon'.
30 days pass. Probably more. Only Then do they buy a CD, encounter some sort of 'problem' and remember, 'aha, theres that trial version I downloaded! Where did I put it again?'
It doesn't matter. Without ever being used, the 'trial' has timed out.
I can't count the number of software tools that have fallen into that bucket for me. The day a piece of software is recommended to me, the day I see a positive review on lifehacker, is NEVER the day I actually have a need - or even the time - to use / analyse the program I've downloaded and intalled.
Having the software expire after 30 calendar days is bad because what if someone downloads it, runs it once, and then decides they'll evaluate it a month later? Next time they launch it, a month later, it'll say it's expired.
I'd go with having it limited to 14 launches, or something like 120 minutes of use.
As for implementation, a file (hidden or not) in the user's Preferences folder, with an obfuscated name, seems like the best way to go. The file isn't randomly placed on the hard drive, but the user can't easily figure out which file to delete.
The least evil way is to just ask the user to delete the program after one month or pay for it ;)
We did it for one of our client application. Granted it was done in .NET for Windows, but the same principles can be applied in MAC.
Like eckesickle mentioned, if your user have access to the internet (or should), then you can have a web service that will register some unique id from the host computer with the starting date trial (MAC adress is a good one). With this, the user cannot really cheat the program unless he chances his network card every month.
Now, if the user doesn't have access to the Internet for some reason, you can either shut down the program until he connect to it or use a grace period. This file records the last time the app is opened. When the Internet is not accessible, we stop writing the time (we still write something in it so the user doesn't notice the file is not updated).
Should a user notice that this file contains the information and delete it (or change it using a copy he has), then you need a way to counter that. You can have some other value in another config file (encrypted always) and check for consistency. What you do if you discover that the user is trying to cheat is up to you, but we force the user to connect to the internet for it to work.
It might be overkill for a program, but it definitly works.
At the time of download, provide them with a trial serial number. When they enter the serial number, have it connect to your server and gets expiration information (stored and encrypted locally to prevent any additional "phone home" calls).
By doing it this way, you make it fairly hard for them to get around your 30-day window, as the expiration date is permanently stored on the server. You could set it up so deleting the key and re-entering it would cause your application to connect to your server again and download the same expiration date as before.
Or you can do it like WinZip does (or used to do it?): Provide a 30-day trial and just pop-up a screen at every load that shows how long you've been using it and links to purchase.
I used to offer a 30-day lite edition of my iOS app that embedded the install date and various record dates in the export data file that the user could download to his/her computer.
If the user was a cheapskate and just reinstalled the lite edition and tried to re-import the data, logic would notice that at least one of the date was older than 30 days and the app would set its install date to the earliest such date from the file, rendering it expired again.
In the full paid edition, this logic didn't exist and the data file could be imported easily.
It was a pain supporting people in this data migration (since apps are completely sandboxed from one another) and some other users felt the lite edition was enough for them so they never upgraded.
I've since stopped offering my lite edition and just reduced the price of the full edition. Now potential customers just have to pay a small amount or go find some competing software.
All in all, that was the best strategy for getting paying users.
Read an UUID from some hardware component and make a check against your web service to see if your software has already been installed for 30-days upon program launch?
Disclaimer: This is not actually a programming question, but I feel the audience on stackoverflow is more likely to have an answer than most question/answer sites out there.
Please forgive me, Joel, for stealing your question. Joel asked this question on a podcast a while back but I don't think it ever got resolved. I'm in the same situation, so I'm also looking for the answer.
I have multiple devices that all sync with MS-Outlook. PCs, Laptops, Smartphones, PDAs, etc. all have the capability to synchronize their data (calendars, emails, contacts, etc.) with the Exchange server. I like to use the Outlook meeting notice or appointment reminders to remind me of an upcoming meeting or doctors appointment or whatever. The problem lies in the fact that all the devices pop up the same reminder and I have to go to every single device individually in order to snooze or dismiss all of the identical the reminder popups.
Since this is a sync'ing technology, why doesn't the fact that I snooze or dismiss on one device sync up the other devices automatically. I've even tried to force a sync after dismissing a reminder and it still shows up on my other devices after a forced sync. This is utterly annoying to me.
Is there a setting that I'm overlooking or is there a 3rd party reminder utility that I should be using instead of the built-in stuff?
Thanks,
Kurt
At least for PCs, the fact that you dismiss an item does get sync'd, and fairly quickly for me. I'm not sure why phones don't seem to do it, though. Maybe the ActiveSync protocol doesn't offer that option.
I don't have an answer, but I feel your (and Joel's) pain every time my cell phone and my computer both buzz me within minutes of each other.
Thanks from me, too :)
Maybe it's because all your devices clocks are synchronized to a time server, so they all have the exactly correct atomic-clock time, and all the devices notify you within a couple of seconds of each other, so the "dismiss" synchronization just doesn't happen fast enough.
I'm assuming that the "client side" implementation is not standardized. For example, if your phone is already showing you a reminder-pop-up, the Outlook synch mechanism can't enforce removing that pop-up since it's device specific. The fact that it does so on "computers" leads me to assume that the protocol DOES support this, but some phone vendors just don't implement it.