I'm developing the first app I would like to release on the play store, and I can't seem to figure out what would be the best way to store data.
User's will input a lot of numbers, which will be used to create different type of graphs. For that reason I need to be sure the data will never be lost, even if they use a new/different Android device. At first I was thinking about a database, but I'm still not sure if my app will be popular enough for me to host a database and spend cash, so I figured it wasn't the best option. Plus, it would require users to create an account.
After some thought I thought I could give the user's the option to either not create an account (but might lose their data in the long run) or create an account but I would still need to maintain a database.
Someone told me they hate creating accounts and said I could just use the Google Drive API for Android. I was looking at the doc and looking at some examples but it is a bit confusing. I would like to read/write/update a sheet, but I can't even seem to find examples on how to do that. There would also be Dropbox.
What would be the best option, in my case, to store data?
I think what suits you best would be Google's Cloud Save, I've never used it but it sounds like it will suit you best!
I'd go with Google Drive. I use it on my app. You have no cost, and almost every Android user has a Google Drive account. Keep looking and you will find good tutorials about it.
Or you could use also Parse. Very easy to work with. And free until a certain usage limit. www.parse.com
Related
Currently, I'm looking to see if there is a way to sync the information we've obtained through an online site with the information we use on a phone application.
All I need to know is that the user that visited our site is the same user that is using our phone application, No stats and preferably no one needs to enter a thing.
You won't get that from Apple, because of their history with privacy concerns, but you could do something like generate an identifying number in your app, that your web site asks for, that would tie the two together. Of course, you'd have to make allowances if your app is deleted from the device, then re-installed, to either make sure you're generating the same number, or other such solution as befits your requirements.
The first thing that would come to my mind is Google Analytics, available for different platforms and services (i.e. Youtube, etc). You would have to go through Google Analytics API to figure out a way on how to track a particular customer visit across several location/platforms.
See Hello Analytics example of Google Analytics API
See Data Feed API
Ok, so far I've answered my own question for androids. Apparently you can pass a referrer param through google play which actually allows your app to receive the parameter and they even have an app that test this functionality.
https://play.google.com/store/apps/details?id=net.stevemiller.android.referrertest
now I have yet to test this, nor is it a possible solution for iOS.
I was in search of an API which would help me get the details pertaining to different applications from playstore. After much googling and going through many solutions already given at SO, I decided to go for Android Market API though this API has few drawbacks.
I am mainly focusing on getting the reviews pertaining to an application - the major drawback here while I use this API is that, I do not get the reviewer name, app version, device and many more valuable information I need.
I have made enough of research to find any alternate methods are there to fetch this information, but to no avail.
During the research, Appmonsta api came to my notice, which claim to provide almost all the details available in the playstore, including username, device, app version etc.
I am sure they would not be maintaining a database which would not be a practical solution, as the market information is prone to change every second. And I am also quite sure, google would not be providing any update to them alone.
Since I am in need of such an API, I am curious to know, what would be the mechanism/technique they use or one should use, such that the whole playstore information is available to them alone - atleast the complete details pertaining to a review.
Any help, comments, guidance in this regard is much appreciated.
There's no official API so whatever you use you shall expect problems - if not today then maybe tomorrow, when Google change a thing in the store. But anyway, you may take a look at the Andlytics sources: https://github.com/AndlyticsProject/andlytics - maybe it'd suffice for your needs
I am sure they would not be maintaining a database which would not be a practical solution, as the market information is prone to change every second.
If I were writing such a web API, I would in fact maintain a database and use it as a cache. New hits for a particular app page would potentially refresh the cache. The information would be obtained by scraping the web page.
The WhereDat API searches the Android Play Store. It lets you find apps, using full-string search queries. It also supports auto-complete use-cases by using prefix-string search. The lookup API lets you get data about apps using their package as the key.
I've been training myself up in Android development. I have an idea for a series of apps that all relate to the same basic data store which stores similar/related hobby data. I suppose in my mind access to this data should be similar to how many apps make use contacts. So I started reading up on content providers but from what I can see they don't actually provide the flexibility I require.
What I want is to create say 4 or 5 hobby related apps that record similar and related data however a customer might decide they only need a specific one to start with. Later they might decide that one or more of the other apps might also be useful.
The data the apps store is very similar, the core data is the same. So the obvious choice is a content provider. However I can't see the providers offer the flexibility I require. Firstly how does the 2nd app purchased figure out that a content provider is already available and if so not install its own (this seems to be hardwired in the manifest and there is no programatic control). Secondly how would an app realise there is no content provider and install one (related to point one). Thirdly a new app installed might have a more up to date provider or an older provider!
So I don't think the providers offer what I need. I also notice that the databases are sandboxed and providers seem to be the only method for apps to share persisted data, or is there something I'm missing. It actually makes me wonder how for none default installed content providers how useful providers are!
I suppose an alternative method would be for a customer to purchase and app and then later ad on extra functionality but I'm not sure if this is possible and if so where the information is.
Any help would be appreciated.
Steve
Note to moderators: at first I thought I'd consider this an argumentative question, but now that I think again I think it's a design problem. A good one that shall stay here.
The data the apps store is very similar, the core data is the same. So the obvious choice is a content provider.
Yes.
Firstly how does the 2nd app purchased figure out that a content provider is already available and if so not install its own (this seems to be hardwired in the manifest and there is no programatic control). Secondly how would an app realise there is no content provider and install one (related to point one). Thirdly a new app installed might have a more up to date provider or an older provider!
Many apps do this by having a "library app" available in the Market that provides the common functionality that other apps from you may need. You should ask the user, in any of those apps, to download that library app to enable the underlying functionality of the "UI apps". I don't know, maybe I would take that route... after all, you need to consider the namespace conflict of your content provider(s), hence the "library app".
I suppose an alternative method would be for a customer to purchase and app and then later ad on extra functionality but I'm not sure if this is possible and if so where the information is.
Yes, that's what the in-app billing is for. However, that assumes you'd have one app with different features.
Truth is, it's a good question. It certainly caught me thinking. I believe it's up to you to provide one app featuring a suite of features added by in-app billing, or many apps that share a common functionality provided by one central app also available in the market.
About this last problem, I would do what feels more natural do the user. If the apps are really unrelated, subject-wise, I'd provide different apps. If it's a suite-like product (think Office suites, for example), I'd implement in-app purchases. There is also a small security issue regarding the code visibility (enabling by software versus per-download).
Anyway, in-app purchases are definitely simpler and easier to maintain, in my opinion. But if your apps are that big, it could be a waste of space... not efficient.
My 2 cents.
I've noticed lately that some app recommender programs seem to get data off the android market. I'm wondering how I could retrieve information, such as screen shots, description, developer, number of downloads, rating, etc...
I've done many searches and I haven't found any solutions. It would be nice to be able to use that info to be able to see a rating for an app inside an app chooser, for example. Or perhaps be able to track changes and rating over time and version history, etc...
Is there an API to access that information? Is there a way to parse the data from a website? Or is there a complicated hack involved? Any information is appreciated...
There is an API currently hosted on Google Code. I've made use of it in one of my own apps and I think it works quite well. You are able to access everything that is visible in the market including comments and screenshots.
http://code.google.com/p/android-market-api/
Is there an API to access that
information?
Not a publicly supported one offered by Google, sorry.
I was wondering what the most effective way of preventing people from stealing my application (downloading a copy of the .apk online rather than buying it).
I've spent a lot of time on one in particular (Droidbox) and won't be releasing Sync until I can guarantee that the people who are providing illegal copies of the pro version aren't able to.
Anyone implemented this? I've tried checking my package signature verses an the signature of an unsigned copy but it appears to be the same - perhaps I'm doing something incorrectly here. I'm unsure whether people actually distribute the signed .apk in which case I don't think signature validation would work to begin with...
Please note, this question is specific to Android Marketplace Applications - the difference being, application delivery is out of my hands and I have no way of linking between a legitimate purchase and an illegal download.
Now there is the new Google App Licensing available. For deeper information read about it in the android developer blog.
A short summary: Google provides a library that makes a inter process call to the market client on the phone. The market client will then ask the google servers if the signed in user has purchased the app and forward this answer to you. There should be a public key in you developer profile that you need to encrypt the connection to the google server to prevent spoofing of answers. You also provide a application and device unique id with the query to make it impossible to forward approved queries to another device and build something like an licensing proxy with one bought copy forwarding the IS LICENSED answers to other devices.
At the moment this service looks secure enough to protect even the more valuable apps in the market. I will give it a try and maybe come back and leave some more informations after I used it a little bit.
If your app is really popular like an EA game or something this wan't stop users from hacking it. To hack the app somebody has to buy it, then unzip the apk, and edit the bytecode of your app to think that the market send a correct answer. The new byte code can be packed into another apk and can be installed on every phone that allows side loading.
To make this harder you can always try to obfuscate your apk and make your bytecode hard to understand.
There is a single, useful connection between an application buyer and the developer through the marketplace, the forwarding email address provided by google to contact the buyer.
Utilizing the integration callback setting to send buy information to your own server, you can use PHP to send a unique identifier (registration code) to the buy via email (real time as the callback is shipped from google during a purchase. The user then uses this email to register their software using the unique identifier that is then linked to their android ID (or google account username) and the software is "activated" and guaranteed to be legitimate.
Obvious Questions
Why is this a suitable solution when it requires the user to read email? Our market are those people who are capable of buying an application using an android device. By using an android device, it is implied that the user has a google account which implies they know how to use email.
How do I use the email with the unique identifier with my application? Create a content handler in your application that handles something like "myactivator://uniqueid-or-something" which causes your application to communicate to your internal server that keeps tabs on activations. Embed this as a link in the email that the user can click on.
How should I generate the unique identifer? I'm going to use the email somehow - I'm fairly confident google has already made it unique enough to disallow any feasible method of contact information selling.
What about people who have already purchased the software? A lot of options here - none ideal or terrible.
Send emails to all previous buyers
Allow users to activate by typing in their order number (can be obtained by logging into checkout.google.com.
Why bother?
Because some of us put a lot of time into applications and saying "you should just accept pirating" is a slap in the face.
The people that are lax enough to use pirated copies of your application to access their DropBox are probably using their DropBox for piracy anyway. Forget those people. Let them go. Yes, it's a huge number of people I bet, but let's face it, those people were never going to pay you anything anyway. Focus on the parts that you can control, and forget the rest.
Focus on the Android users that use DropBox for their work, for their businesses, for their own code, for their finance, for their thesis, and/or for their private family pictures. 95% of those people, that have something of value in their DropBox, and that want it kept private, are going to want to buy your application (assuming it's good enough for them).
Let me use this analogy:
When it comes to hiring a locksmith to put a lock on your home, do you hire the guy that looks the part and takes $150 an hour, or do you hire the shady guy that is willing to sell you a stolen lock to put on your front door?
Release your own illegal copy in the best known forums and have it disable itself after a week and showing a message like
Thanks for stealing... I make my living with programming this app. The x Dollar won't hurt you and I could by my next meal and go on making great updates for you.
I think this is the only thing that you can do about it. People will always find a way to copy your app and all countermeasures will only disturb the users that paid for the app.
The people copying your app aren't your customers and they never will be. Just see their use of the program as a kind of viral marketing. At least they are talking about your app and maybe some of their friends will then buy the app.
General shareware advice here - license the software to the individual. i.e. provide a license key that is personalized to their username. They'll be much less likely to distribute a key if it's got their name on it. You can probably automate the backend fulfillment of the order, to provide custom keys. Have your "Pro" version operate in trial mode until the name/key are entered.
Don't leave your computers so that someone can steal your applications from there.
Or wait.. Did you meant you don't want others to copy your software? Then.. not publishing it in the first place is likely your best option.
A bit related link: http://news.cnet.com/8301-27076_3-20003120-248.html
You neither have any mechanism to estimate amount of illegally copied software. Enjoy your attempts from stopping the rain even though entities bigger than you have attempted and failed.
There is a new tool in the wild that seems to good to be true:
Automatic Application Licensing from Keyes Lab.
I haven't tried it yet but if this works it sound like something you want to use in your high priced android apps.
If anybody tested it leave a comment or edit my answer with personal feedback.
I have the same issue. I recently found a number of my paid apps available for free download on this site: https://dlandroid.com/
I asked them to remove my app APKs, but I'm sure there are many other similar sites. Presumably they have a rooted phone which gets one valid copy of the app from Google Play, then uploads it onto their web site to distribute to all and sundry for free.
You could spend endless amounts of time ensuring that there are no pirated copies of your apps on the web, or implementing complex piracy protection measures, which would most likely make things less convenient for your genuine paid users. But I guess in the end, you have to be prepared to make a trade-off and accept that a certain level of loss is inevitable, and hope that most people are honest and get your app through the proper channels rather than risk malware infection by going to dodgy sites like this.