I am working on an android app where I need to integrate data from another app.
Just For Example: Think a situation I have google play store in my mobile. Now when a person searches "education" in play store It shows all the result in list which consists that keyword. Now I want to get all the data result fetched by play store in my app.
Note:- I am not sure there is any code to get data from another app, but still I saw an app called App for all taxi cabs It shows all the result from various application even there is no api for ola cabs, Taxi for sure and many others but they are somehow manage to get all these data for their app.
Please help I crucially want to know if there is possibility to do so or not.
It sounds like what you want to do is "snoop" on another app. That is, you want to retrieve data from it that it doesn't publicly expose in it's API.
I believe this is generally impossible without breaking the encapsulation of the app - this means you would have to use more than its publicly documented (and reliable) interface, and delve into its implementation specifics which are liable to change without warning, thus breaking your own app.
There are apps that are able to take screenshots of other apps, this would be one example of how you could indirectly break the encapsulation, as you could attempt to parse the data that way. I give this example purely to prove that it is possible, however this would be considered terrible practice and should be avoided for many reasons.
For all serious use cases, I would say that if it is not provided in the API, you cannot obtain the data.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am working on a REST API where I will have to introduce some breaking changes soon, so a v2 is needed. We still need to support v1 for a couple of months though in parallel, to give our clients time to switch over to the new API whenever they are ready. Our API is offered via shared cloud, and all our clients share the same system backend, especially a single, shared database.
I have found a lot of articles about REST API versioning, but they were all more from a client's point of view, or high-level design point of view. That's not really my concern, our API already has a versioning in the URI, so offering services with a /v2 base path won't be aproblem.
However I am asking myself how I am actually going to implement this, and I haven't really found good articles on that. I don't really want to branch off a v2 of my project and then build and deploy v1 and v2 as separate applications, because then I would have maintenance, bugfixing, configuration changes etc in two applications, which is double work and carries the usual dangers of redundancy (i.e.: possible inconsistencies between the versions). Also, the v2 of course is not different in every service, so most of the code would still be the same.
Is there any best practices on how to technically implement a REST API in a single application that provides multiple versions to the outside, and where some code is shared (i.e.: v2/someService would internally redirect to v1/someService), and just the actual differences are coded in new services? Maybe there's even frameworks that help with designing this? The app is coded in Java with Spring MVC if that's helpful.
I'm thankful for any tips or resources on how to tackle this. Thanks!
I'm also now facing such task, and still having no useful answers.
Though I believe having separate v1 and v2 instances in parallel can still be at least a fallback-solution, I'm currently thinking about a scheme for a single application, which will heavily use the benefits of dependency injection in the application.
So, basically idea is to configure your IoC container accordingly to a received request, so that each and every service would receive a needed version of its dependencies. This can theoretically be a good solution, but it requires an already near to ideal architecture of your application (which is often not the case) where all the concerns are separated, etc. As SOLID as possible, in other words.
At least with this approach, you'll be able to quickly identify all the components of your codebase which require refactoring, though making the whole process not a quick one. Besides, I believe the closer changes approach the core of the application, the more difficult parallel versioning may be, but we will see.
I should point out once more, that for me it's still just an idea which I'm going to research further specifically for my project, so I'm not sure how easy or problematic it will be in fact.
Hope you have seen
API design ensuring backward compatibility
http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/32713.pdf
Having two versions of API in the same application is quiet enough
api.mysite.com/[version1]/api/url
api.mysite.com/[version2]/api/url
Not sure why you need to build and deploy v1 and v2 as separate applications? Unless you are planning for a Zero-Down-time rolling upgrade in production
I like to bring up the following strategies into the discussion, and both are strategies in continuous delivery.
Branch Abstraction
The basic idea is to place an abstract layer in between the clients and your current implementation. Then introduce a second implementation behind the abstract layer. This gives you the opportunity to progress within your normal code base but support new features for your next version API instantly.
See BranchByAbstraction.
Feature Toggles
Add features to your code base without making them visible to your customers. This allows you stay on your main development branch even if things are not ready for end users yet.
See Feature Toggles (aka Feature Flags)
If I were faced with the situation you speak of, I would first try to keep my new version (v2) backward compatible with my first version (v1). If that were the case, you could just add functionality and update your API documentation, keeping only one active code base. I would think you could even add things to the response payload as long as the data coming back would not break anyone's code - sort of like adding fields to an existing database schema.
If v2 was not backward compatible with v1, you could possibly move v1 to another server and notify your users that it is being placed there for a stated, limited period to give them time to make code changes necessary to switch to v2, but also notify them that this version is no longer being updated and if they have issues, they will need to switch to the new version. Hence, v2 is the HEAD version of your code base with no other branches under active development.
I hope this helps and offers something you didn't already think of.
The v1/v2 dilemma is a strong hint that you actually do not have a REST API to start with. Peers in a REST architecture exchange more or less standardized content by clients requesting representations of media-types they understand. This technique is called content-type negotiation. Of course, a badly written server may ignore proposed media-types and send one the client does not understand. This will, though, prevent the client from interacting with the server further. A well-behaved server therefore should attempt to serve a client request as best as it can.
According to Fielding:
A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.] Source
A media type describes how the syntax of a payload exchanged for such a media-type looks like as well as the semantics each element in that representation has. With the help of meaningful link relation names and media types a server can teach a client on the next options available a client can make use of while progressing through its task. I.e. think of a case where a previous response contained a link relation create to the client. The client does not really know how something has to look like in order to be processable by the server, thoug on invoking the URI returned for the create link relation name the server responds with a form like representation along the line of application/vnd.xyz-form+json where this media type defines some input controls the client can use in order to generate a request representation expected by the server on the target endpoint. Similar to the Web the custom form also contains a HTTP action as well as a target URI provided by the client to send the response to and eventually also the representation preferred by the server.
Clients in a REST architecture shouldn't care about the URI, so returning an URI containing either v1 or v2 should be more or less meaningless to them. Fielding even stated that a REST API itself shouldn't be versioned at all! What is important though is that the client and server are able to understand the payload received.
Instead of versioning the URI or API, the media type describing the syntax and semantic actually need to be versioned. I.e. if you take a look at the browser based Web (the big sibling of REST) and here HTML in particular you will notice that it is designed in a way to require new version to stay backwards compatible. I.e. client and server receiving a text/html defined payload will be able to handle pure HTML (1.0) up to HTML5 content regardless which actuall syntax (maybe even a mixture) was used. Other media types, however, might not be that lenient. Here you could either make use of profiles or register a whole new media-type if you think the old and new one are completly incompatible to each other.
Either way, I hope I could shed a bit more light on REST architecture and how you might get there. I am well aware that my suggestion may not be easy to achieve, though once you got it you basically decoupled clients from your API and gave the latter one freedom to evolve while not having to fear breaking clients. There will still be a coupling but both, client and server, will couple to the media types rather than to each other. Before creating a new media-type it is probably worth looking for already existing ones
I have developed a few apps in my days, but only small local applications.
I want to start working on more advanced apps, and I have a few ideas that require me to keep track of usernames, scores etc, Online.
Lets say im looking for a way to keep track of usernames/passwords, making sure the usernames are unique, and updating the client sqlite database aswell as server database whenever they go online.
So far the only ways I can think of is creating a java servlet or posting and recieving data through PHP and into a MYSQL database. (which I have done some testing on... and I dont really like it).
What is the common/best way to do this? Can anyone nudge me in the right direction?
Essentially what you need is a web service hosted somewhere to perform the tasks you need, such as ensuring unique usernames etc.
I would suggest creating a REST service for this, perhaps look into JAX-RS for this, but any REST framework would suit you.
On the Android front, you would need a (de)serializer, such as Google's GSON which will enable you to convert Java objects to/from JSON seamlessly.
Finally, something like Square's RetroFit will make it much easier to call on that external REST api from your Android code.
These are just a few of the possibilities - there are alternatives to all of these libraries if you don't like any of them.
How could one easily store some data in a simple GAE Google App Engine Application? Like username or some Address information, that should be available again if the application is either restarted or redeployed due to an update.
Is Datastore the way to go? Or what should I have a look at?
You can either use Datastore or Cloud SQL. The Getting Started Tutorial is actually demonstrating how to use the Datastore in case you haven't play with it at all.
From your question I am assuming the credentials are required for connecting to other services, rather than individual credentials for lots of different users.
So on that basis if you need to change them frequently then consider the datastore.
If infrequently and you don't mind updating you code base, then leave them in the filesystem.
Other things to consider how senstive are they, who can see them.
You may have more people that have access to the datastore than can deploy/download code base (assuming you left that capability turned on) which may also be a deciding factor.
I am pretty far into my first Android application, and I have the sneaking suspicion that I'm "Doing It Wrong". My app talks to a Ruby on Rails server and serializes objects back and forth via XML. Before I knew what was happening, I found myself knee deep in writing my own crappy ORM, a problem which is compounded by the fact that I haven't written any Java since high school.
My conflict here is that I want my client-side (android) app to be capable of serializing via a variety of methods, such as HTTP/XML, to a local database, or out to the local filesystem. I started out with the Strategy pattern, but I feel like my solution is badly lacking.
For one, should I re-implement all of Rails model validation on the client side, because I don't know if I'm always going to be working with Rails on the other side? The even bigger issue is that right now I can only represent flat objects as key-values, as my code can't handle nested objects like a true ORM.
I'm sure Android devs deal with this all the time, so I'm interested to hear what other people do to cope with these issues.
I wouldn't approach your Android application as an extension of a Ruby app - rather a consumer of an API. If you can try to expose your server application as JSON (or other format, but JSON is the most lightweight) and consume these APIs from your Android application you would most likely have less problems as JSON is already in K/V format.
I have not yet written Android objects to SQLite yet, but I have written them as both Parcelable objects and to the SharedPreferences. Both of these strategies are sufficient for small to mid-range apps. For data intensive apps, obviously you will have to take it a step further to SQLite.
There are some great articles for these approaches: Managing State.
It boils down to designing your objects in a way that can be serialized easily. That means no circular references or extremely complex objects. This shouldn't be a very large problem, especially if your data is in JSON format already. You simply need to extend some classes and add functions that return a Parcelable object representation or a string representation so your objects can be saved thus.
I would avoid cloning your server-side objects and validation in Android as it then requires modifying both sources if you make small changes. The server should handle all data and validation and you should simply be requesting, caching, and sending data from Android.
I'd be interested to hear if there any challenges to writing objects to SQLite, but I imagine it's not that much more of step from the details I've outlined above. Hope this helps in some capacity!
Hessian is great for RPC. You don't have to do any serialization yourself. It doesn't use XML, so it's more efficient and more appropriate for a mobile platform.
I haven't done much of persistence storage on Android but I think you need to use SQLiteDatabase and make your own Cusor that De/Serializes your object so that it can be added to the database. A possible solution would be to extend a SQLiteCursor or an AbstractCursor.
Otherwise I don't think there is other solution apart from, possibly, "hardcore" Serializabled (Which I suspect it may be too much for a phone, I may be wrong)
I think you might be going too heavy for a smart phone application. I would look at using RESTful style web services with JSON content.
Looking to your question I got the feeling that maybe you just over-complicating your requirements? Why can't you just use JSON format to represent your objects data in portable way? Then you will be able just to store it either on file system or in database in simple text field. You can leverage android-active-record library for transparent DB persistence (http://code.google.com/p/android-active-record)
The application is vb.net front end and sql server express backend. The networks are always cabled LANs.
Installations are small with only a few users, none of whom would have any technical knowledge.
Very little technical support is ever called for and I'd like to keep it that way.
I don't know Java or Objective C or HTML/CSS/Javascript which as far as I can see seem to be the choices for smartphone development on Android, iphone or web based application
I want users to be able to access as much of the functionality of the application as possible for the least effort both in terms of coding and acquiring new skills on my part.
I don't know where to start or which would provide the easiest path.
I don't know how to make the database available to smartphones whilst keeping it physically secure in a small office.
If all things were equal I'd probably learn towards HTML/CSS?Javascript as it seems to be the most widely applicable.
On the other hand maybe I should wait for win phone 7?
To reach the largest number of users in a device independent manner then delivery via browser is going to give you the best results for the least effort.
If you have designed you existing application with a Data Access Layer, a Business Rules Layer and a User Interface layer, this may be as simple as creating an ASP.NET UI for mobile/internet/intranet users.
If your appliciaction is not designed this way, then my approach would be to seperate out the code in you existing into these three layers, or at the very least seperate the UI layer out of the existing code. Then it just a matter of implementing a UI layer for each access method you plan to use.
That way you end up with a lot less code to maintain, and when the businees rules or backend data changes you only have to do the change in one place for all you User Interfaces.
Well, .NET Compact Framework is already avaialbe on WinMobile, so you defenitely should give it a try if you're free to choose which mobile OS to target.
If not, I suppose that for task like this it would really be better to use web interface. If you don't now HTML/CSS/JS - as for me it's not a problem but a great chance to learn new interesting trendy things! :)
I would go with a simple html app designed for a mobile screen.
Android or iphone will only get a % of your users. If you want to get them all, you would need to write in both (and then blackberry and winmo are SOL).
So without seeing the application, it is very hard to know how much work converting vn.net to something you can get at from a web browser would be... but I don't think it would be much worse than a port to android or iphone, and it will allow a much bigger market to view.
Either way, you will need to learn something new. Learning is good though, right?