I would like to get some stats programmatically about my app; for example: total downloads, active installs...
I wish google would give an api for doing this. What do people do?
There currently is no API, and it is possible to get these statistics, but it's quite complicated (you have to get an AuthSub token for the market developer service, and then do the right requests and parse a number of GWTRPC encoded responses. These GWTRPC responses change everytime they launch a new version of the android market dashboard, so be prepared to monitor frequently whether this has happened).
In a recent chat with one of the Android folks from Google I heard that they are aware of this issue and know that it's a very popular demand by developers, so hopefully there will be a better way soon.
Related
I am interested in building a tool that allows business to manage DMs from a web app.
I'm wondering if anyone has any experience working with Instagram's API in this capacity, and if so, whether there is any red tape to be aware of.
I very much appreciate the insights!
Currently, there is no API for Instagram DMs. There has been no mention of opening up in the future, either.
I apologize for the question but I don't have the resources to figure it out myself.
I'm looking for features my next iOS / android app should have and as you can imagine, I'm interested on a "pinch of social" that's why getsream seems to be my saver.
After reading the getting started section and the documentation, I found this warning http://getstream.io/docs/#mobile that confuses me.
I supposed getstream is a managed service that takes care of everything letting me use the REST API to build my mobile community within their phones.
Could you please tell me where I'm wrong?
Many thanks
There are two main reasons we do not recommend integrating Getstream client side (i.e. in the browser or on mobile). First, it is hard to guarantee security when you integrate from the client-side, you have to somehow provision tokens for each user's feed (and feeds they want to target with activities http://getstream.io/docs/#targetting), you could also generate an application wide (read/write) token and ship this to all clients but this is also a bad idea for obvious reasons. Second, we do not recommend using Getstream to store all your activity data, you store references to objects in your local database and enrich the activities from getstream at read time (have a look at our integration libraries for Django/Rails).
I've been using instagram's real time push api (http://instagram.com/developer/realtime/) for a long time to get updates on a specific location. I use the highest possible value for "radius", which is 5000m . For the last 4 weeks, I have noticed that I received significantly less updates through the API (but not zero). Other applications seem to have the same issue, like http://now.jit.su/ . I also filed a bug report at instagram, which went unanswered.
My questions are:
- has anything changed in the API?
- has anything changed in the app (so that not every photo will be published)?
- is anyone else experiencing this issue?
- is there anything I can try to get it working again?
I know this is not exactly a perfect SO question, but I was not able to dig anything up on google, and the instagram developer pages direct here for support. Any help is greatly appreciated.
Had some communication recently with a contact at Instagram and he mentioned that Instagram's real-time functionality will be limited to only user subscriptions in the future.
Apps created before November 17, 2015 will continue to receive updates but are being sampled because of the load they are experiencing and the fact that the architecture used for this does not scale well. He also mentioned that, as a result, real-time subscriptions will be deprecated for Tags, Locations and Geographies.
The developer guides also have some information regarding this:
OLD: https://www.instagram.com/developer/deprecated/realtime/
NEW: https://www.instagram.com/developer/subscriptions/
I am using https://api.instagram.com/v1/users/self/feed?access_token=AccessToken&count=100 to get my feeds.
You might be missing count in your api or let me know which api you are using
We are evaluating various error reporting services for iOS and Android apps. Our app uses webservices to connect to the server.
We currently use Flurry analytics but have not yet used their new error reporting feature.
What is your feedback on Flurry error reporting, if you are using that today?
I am trying to compare it with Crittercism and Crashlytics. So, if anyone out there have experience using Flurry error reporting and Crittercism or Crashlytics, it would be great to hear your feedback.
Thanks.
While this question is likely more suited for a forum, I'll do my best to answer your question from my experience with these technologies as well as what I've heard from others. First lets look at what these services provide for Crash Reporting, then lets look at what they provide that ties into Crash Reporting.
Flurry provides (at a high level):
Analytics of event based metrics (this includes optional basic crash reporting)
server-side symbolication (however uploading symbols is a manual process)
All this is great, but they really don't focus on crash reporting at all or how that ties into other metrics.
Crittercism provides (at a high level):
real-time insights on reports (system diagnostics, logs, etc)
smart crash/error grouping
error monitoring with actionable diagnostic information
logging non-volatile errors
server-side symbolication for stack traces
location correlation with above metrics
session based metrics for a crash report
client perspective network performance data (note: this would be great to keep track of your web services and other 3rd party services, such as Flurry, to see how they're performing)
trends of above metrics and data
connection between network calls and crash/error reports (look at breadcrumbs)
See the above link for more details on the full package that Crittercism provides. For more details on some of the features, check out this page.
All of these are focused on giving you full visibility on how your app is performing for each of your users.
Crashlytics provides (at a high level):
smart crash/error grouping
error monitoring with actionable diagnostic information
server-side symbolication for stack traces
logging non-volatile errors
real-time insights on reports (system diagnostics, etc)
Flurry can be paired with more robust solutions for Crash Reporting and in my experience most end up taking this route.
Crittercism provides a lot more than just Crash Reporting that ties back to optimizing the performance of your applications with actionable data. They also hook into Mobile-ready support systems (such as UserVoice and HelpShift) for better customer communication, and several task management systems for engineering (JIRA, Github, Pivotal). Server-side symbolication, APIs to pull data, simple integration with build tools (such as Jenkins) provide a much more mature solution.
Crashlytics provides an easy integration for the average developer. I've heard complaints from developers with more defined build processes (such as something that uses Jenkins) that their app integration for uploading symbols for symbolication gets troublesome.
They also provide integrations with JIRA and Github. Not sure at what level.
Some love the UI for Crashlytics, whereas others have stated that it gets in the way.
Hope this helps.
I have been using Crashlytics pretty much since it first launched for Android and iOS. It's a pretty impressive system with some massive pros:
Extremely lightweight library
Compatible with major development environments
Real time insights
Crash grouping
Individual crash breakdown
Tagged with user information
Custom keys/logging
Email alerts
Impact level changes
New bugs
Daily summary reports
User management for sharing access
It's free
There is also a split between crashes and non-fatals which means you can report handled exceptions back without having the app crash. For example, in our Logging class we have this method which gets called when an exception could happen, but shouldn't. This means that we have a breakdown of how often this happens and we can work towards resolving it:
// Android
public static void log_wtf(Throwable throwable)
{
Log.wtf("Log", throwable.toString());
// Also log this exception to Crashlytics
Crashlytics.logException(throwable);
}
I particularly like the crash breakdown which lets you see each individual crash report from a group of reports. You can ask the users to use their name, or do what we do and sign it with their login credentials for our service (see the user info on the right):
This is invaluable information for us which allows us to easily and quickly reproduce the error.
You also get a version breakdown which you can disable at a later point. For example, if we have just finished a test of alpha version 0.1 (1), you can turn logging off for that version and launch version 0.2 (2). If someone forgets to update their application you will not be notified of anything from that point. Obiviously this isn't good when your app is in production, but useful for testing phases.
While I haven't tested it they have integrations for other services including your own web hooks if you wish to develop something to support it. It's in my plans to do this to automatically create trac bug tickets, however I haven't got around to it yet!
Oh, and finally, let's not forget the sweet animations crashlytics employs throughout it's software.
I would recommend going with Crashlytics. They have the smoothest onboarding process of any error reporting software. It's very easy to setup and incredibly intuitive to use. The reporting is immediate and spot on. They also have the best console UI of the bunch. I've used them now at Evernote, HomeAway, and my own apps and I've never ran into any problems. They also have a great support team that responds very very quickly, normally within minutes to inquiries.
I've also used Flurry in the past, for event tracking, with mixed results. Their numbers always seemed to be a bit off. You also have to go through and add start/stop events in every activity which can be a pain.
I exclusively use Crashlytics for my day to day app crash reporting. The UI at times can be a little flashy and navigating the site is sometimes a hassle but overall they provide a reliable and well built product. It's certainly useful when distributing app betas and as an intermediate to advanced iOS developer, I've never had any problems integrating their SDK.
Pros:
immediate crash reports
real time insights
interaction time is minimal i.e. the time spent once a crash email is received to the bug being fixed is small. On average I spend 30 seconds - 5 minutes on every crash report simply because Crashlytics makes it very easy to find my bugs.
great customer support
installation is a breeze
lightweight
Cons:
UX on the website isn't as refined as it could be
navigating the website takes some getting used to.
I work for Grid, an iOS app startup based in San Fran and we use Crittercism there but all in all, Crashlytics is the one I end up using. It comes down to ease of use and they've got that nailed down.
EDIT:
Crashlytics was also recently bought by Twitter so there's plenty of talent and infrastructure there.
I've not used Crittercism or Flurry for crash/error reporting, but have been using Crashlytics since its inception. I'm not convinced there's a better crash reporting solution at this point.
Reasons why I think Crashlytics is great:
Super lightweight
Super easy integration
Awesome stack unwinding
Ability to provide custom logging
Web UI response has greatly improved
Provides symoblicated stack trace
Smart culling of crashes on web UI
Easy crash searching on web UI
Basic stats via web UI
At the end of the day, it comes down to what tool works best for you.
As said before Flurry don't focus on crash reporting at all or how that ties into other metrics
Before Crashlytics android's release I was using Flurry but had some problems with documentation and support (you can see here) and they didn't corresponded as I wished.
In my case, crash and errors are a very critical point cause, so Crashlytics worked like a charm.
A good documentation
Great support
Easy Configuration
Real time insights (Flurry hasn't)
In short, I have not experienced nothing better than Crashlytics yet (Talking about Error Reporting)
I use Crashlytics since a year now (edited July 2014), and the system is really awesome.
Realtime crash report works very well, with their reports we are able to fix them really quickly, it's a huge & priceless feature ! CL solution is available on multiple platforms, it's really easy to plug it in XCode 5, Eclipse or IJIdea with less than 5 lines of code.
You can create multiple enterprise, to separate your projects, just with a couple of clicks
I have to mention that support team is fabulous, I've exchange dozen of mail about it and their answer always solve my little probs.
It's completely free, own now by Twitter, and very very light.
I gave a conference about Craslytics solution a month ago, slides are available on my speakerDeck profile here.
Reading through the Flickr API documentation it keeps stating I require an API key to use their REST protocols. I am only building a photo viewer, gathering information available from Flickr's public photo feed (For instance, I am not planning on writing an upload script, where a API key would be required). Is there any added functionality I can get from getting a Key?
Update I answered the question below
To use the Flickr API you need to have an application key. We use this to track API usage.
Currently, commercial use of the API is allowed only with prior permission. Requests for API keys intended for commercial use are reviewed by staff. If your project is personal, artistic, free or otherwise non-commercial please don't request a commercial key. If your project is commercial, please provide sufficient detail to help us decide. Thanks!
http://www.flickr.com/services/api/misc.api_keys.html
We set up an account and got an API key. The answer to the question is, yes there is advanced functionality with an API key when creating something like a simple photo viewer. The flickr.photos.search command has many more features for reciving an rss feed of images than the Public photo feed, such as only retrieving new photos since the last feed request (via the min_upload_date attribute) or searching for "safe photos" only.
If you have a key, they can monitor your usage and make sure that everything is copacetic -- you are below request limit, etc. They can separate their stats on regular vs API usage. If they are having response time issues, they can make response a bit slower to API users in order to keep the main website responding quickly, etc.
Those are the benefits to them.
The benefits to you? If you just write a scraper, and it does something they don't like like hitting them too often, they'll block you unceremoniously for breaking their ToS.
If you only want to hit the thing a couple of times, you can get away without the Key. If you are writing a service that will hit their feed thousands of times, you want to give them the courtesy of following their rules.
Plus like Dave Webb said, the API is nicer. But that's in the eye of the beholder.
The Flickr API is very nice and easy to use and will be much easier than scraping the feed yourself.
Getting a key takes about 2 minutes - you fill in a form on the website and then email it to you.
Well, they say you need a key - you need a key, then :-) Exposing an API means you can pull data off the site way easier, it is understandable they want this under control. It is pretty much the same as with other API enabled sites.