Tagged with [android] so that someone will actually read this, but applies equally to other application platforms.
We have a number of Android and iPhone applications which have user-feedback functionality incorporated into their user interfaces. These allow the user to leave comments, report bugs, rate the application, request support, etc.
Currently, the applications make a web service call to our backend, which converts them into email and sends them to us.
We would like to replace this with an API call to a remote backend service hosted by someone else, a service that specialises in this sort of thing, and provides us with a web interface for viewing and collating the feedback. The API would need to support arbitrary fields that we can set up as we see fit.
I was hoping to somehow integrate this with the Google Analytics APIs for Android and iPhone, but it's not flexible enough. The likes of FogBugz would seem to do the job, but it's too heavyweight a solution - we don't need anything that fancy.
This question touches on the same issue, but concentrates on self-hosted software. I'm looking for a service provided by someone else.
Free services preferred, for obvious reasons, but commercial options considered also.
You can look into userrules.com. We expose an API to collect feedback which is available with all plans. Also with single plan you can configure your all applications as separate products. Lots of iphone apps are using our API to collect the feedback and then our Admin to manage those.
I've heard good things about GetSatisfaction http://getsatisfaction.com/
UserVoice as well http://uservoice.com/
www.SimpleFeedback.com offers a feedback service that has a web service API for you to submit your feedback. You'll have to map your fields to our defined fields. Along with basic fields like name, email, rating, and comment, we have two custom fields called feedback type and feedback category. You get to define the types and categories. For example, you can define the types to be "Bug Report", "Suggestion", "Question", or "Testimonial". Categories are subtypes. Each Type has its own set of Categories.
We can notify you via email when feedback is submitted. Our SimpleFeedback Center stores all your feedback and provides a nice UI for reporting, sorting, filtering, responding, and other feedback management tools.
We also provide a feedback button and feedback form to use on websites who do not have their own form. We have a plugin for self hosted WordPress blogs, too. An iPhone feedback form is also available for developers who don't want to write their own.
HelpStack has both free and paid solutions. In free solution you will have to communicate via Email. For paid solution, you will have to go with ZenDesk, HappyFox or Desk.com. It supports both iOS and Android. I haven't tried it yet, but it looks promising. It also has a FAQ section support.
Edit : I just tried the free solution. It simply opens an email app, nothing else. It does have a FAQ section, but no chat support.
Related
I'm creating an App in which the user has to provide his credentials for a third party web site. My App uses this credentials to login in that website to perform some automatized tasks via Jsoup.
The problem I see is that when credentials are sent from the App to the Website, they could potentially be intercepted. Is there any way I can encrypt that data?
Credentials are not for a particularly critical service, it's nothing that deals with money or stuff like that, but I still do not want to expose passwords.
It's great that you want to keep your user's credentials safe. That's a good thing even if the service you're using is non-critical, since many users will typically re-use their passwords across sites.
As for what can be done, that will depend on what the service you are trying to use supports. The first question is whether the site uses HTTPS. You should definitely use it if possible.
Some sites also provide their own API's for interacting with them without going via their web-pages. I assume that may not be an option for you, since you are using JSoup, but if it is an option, look into what security features they provide that way.
If nothing else (or possibly in addition to anything else?), you might consider adding a section in your app with a paragraph with "recommendations for secure usage" or something along those lines. Urge your users to use a separate password for different sites, or at least for that specific site, to reduce risk. Be careful not to push it too much though - you want it to be a friendly reminder, and not a constant nagging.
I have been searching for a proper answer to this question, have a bit of background in front end development, but with new concepts like SaaS, PaaS, etc. want to get information from experts out there, that could help any newbie to understand what it's all about.
Say I am trying to develop eBay like an app that takes a product from a user and sells it back to the other user who needs it.
Will my app need a backend server? If so why? I am already uploading my app to Google Play Store or Apple Store.
How will the backend server like HEROKU or FIREBASE or AWS help my app?
Can I implement two different services in single app, say for eg., firebase for backend database and HEROKU for payment processing?
Thanks again for your time and information.
SaaS
Answer: SaaS stands for "Software as a Service". In layman's terms, someone developed some software and hosted it somewhere. You can use that hosted software in your software project/product as a third party service (like public API); or directly use that as individual software under some license like Firebase as mentioned.
PaaS
Answer PaaS stands for "Platform as a Service". In layman's terms, someone configured some hardware and exposed the hardware controls via some web based application or REST APIs. You can use that hardware to deploy/run/manage your application without having the actual hardware on premises.
Backend Server
Answer First of all, let me explain the server. The server is a middle-man who serves whatever is requested of it, and all browsers/mobile apps act as client. So for example, the web is all about client-server communication.
So taking the example you mentioned, an eBay-like app takes a product from a user (client action) and puts it on the server (client requests in background for server to put product on server). Then another user opens the app (client action) and searches for the product (mobile client requests server to return that product, if valid and matching search criteria), and then he can buy it (mobile client will request server to complete the purchase).
You have to understand that for any communication between web application, mobile application or desktop application, there will always be a server. Even in file sharing applications like shareit, one mobile app works as server and same mobile app elsewhere works as client.
Yes, backend servers like Heroku or Firebase or AWS will help your app to complete your application business flow.
Yes, you can implement two different services in single app, say for example, Firebase for backend database and Heroku for payment processing or hosting your application/APIs.
Unless you are experienced with building distributed applications that can persist data across multiple nodes in a consistent manner, and ensure data available, I'd say you most definitely need some kind of backend. Unless of course you only plan to have user-to-user transactions, that can rely on direct messaging between client applications - which seems pretty pointless and quite far from the requirements of an EBAY-like product.
In terms of the architecture, you can follow many different approaches, but in most of them you will require some sort of data access layer. I'd recommend looking into the three-tier software design pattern (https://en.wikipedia.org/wiki/Multitier_architecture) to better understand the way this type of software product is typically designed.
After sorting out which type of data persistence you prefer, you'll need to setup the backend where your mobile app will connect to retrieve the data from (things like products being sold, user profiles and ratings, your own history). Of course you could also connect directly to the database from the app, but that would be a big mistake - it would meaning making the DB access publicly available, and thus exposed to attack, not to mention that you would be hard-pressed to find a solution for user registration and authentication, which would have to be provided by other means anyway. Typically your backend will also manage user registration and authorisation.
Heroku, Firebase and AWS are all very different, each with their strengths and weaknesses, but there's nothing like trying them out to see what fits best. What you refer to as "Google Server" and "Apple Server" sounds like a misconception, and you probably mean the Google Play Store and the Apple Store. These are not applicational servers that you can use as a backend, and serve only as a repository for your mobile app from where users can download it, and nothing else.
Without some sort of backend mechanism, the challenge of making data available for the consumption of multiple users would be overwhelming.
I know this isn't a very specific answer, but your question is quite broad-reaching, and it seems you need to look into some basic fundaments of software engineering before going into more detail.
I'm busy building an app for android. When it's properly received by Android users I would like to expand to iOS.
But, before we get there, I first want to make the right choice. So my question, what to do?:
writing all the logic inside the app and use Cognito (https://blogs.aws.amazon.com/security/post/Tx3LP54JOGBE0AY/Building-an-App-using-Amazon-Cognito-and-an-OpenID-Connect-Identity-Provider) to access the data from DynamoDB
or let my app connect with my own API which handles the validation rules, which I then connect with DynamoDB database (don't know or API -> Cognito -> DynamoDB is a better solution, didn't really used it yet so...).
Now we all know about those issues where hackers built ways to bypass certain validation rules (as far as I read, most commonly by decompiling the app). I really want to avoid that!
So what do you experienced Android developers use? I know the answer seems obvious. But the reason I ask this is because I would like to avoid having my infrastructure, which I need to update etc. But to be able to register users, without the need of an third party which supports OpenID like twitter, facebook or Google, AND secure my validation rules, it seems like I have no choice. Or do I?
If you are targeting multiple platforms, it's usually best to conduct the majority of your business logic in an api outside of the app. It reduces code duplication and if validation is done at the api level, it limits the ability of malicious users to bypass validation rules.
With that said, running your own api doesn't necessarily require running your own infrastructure. Two AWS web services that could help are Amazon API Gateway and AWS Lambda. Registering your users can be done using Amazon Cognito Your User Pools.
If I am building an Android app that uses the Facebook SDK and also has a web app that has most of the same functionality, how should the Android app handle social actions? Should it directly make requests to the Facebook API through the SDK or should it post to the web app server through my own API and allow the web-app to make the request to Facebook on behalf of the Android app? Most of the Facebook for Android examples use the former approach however none explicitly discuss the best practice when there is a web backend that will have the same social functionality as the Android app.
I've been putting my mind into a similar problem before. It was a PHP app, but essentially the design choice was to either put the FB-interaction into the frontend (JS-SDK) or into the backend and proxy it (PHP-SDK). Sadly haven't found much guidance either, so I had to make up my own mind.
As so often there seems no per-se answer, it depends on what you are doing with FB and how deep it is integrated into whatever your app/webapp/backend are doing. Is your Android otherwise more a client-side app or does it rely on other features delivered by the web-app via web-service? Is it somehow integrated with users actions that are dispatched to the backend, or does it just offer some additional gimmicks (e.g. 'Like' button, anything in the lines) Are you using the SDK to authenticate and pull user related data from FB (email, name) and does that information play a role in your backend?
As I see it, it boils down to the following:
Direct communication with FB is a lot simpler to implement as you won't have an additional layer between your app and FB, i.e. proxy code, etc. So if FB is just loosely coupled it's likely the 'good-enough' option.
Patching FB from frontend to backend can get nasty - especially if you want to authenticate via FB it's kinda complex at first. However, you'll have all FB logic in a single place, shared by Android-App and Webapp, so it's obviously easier to maintain later and better to integrate with other interactions your backend might be offering.
Hope that provides some value, would be eager to see other opinions too.
Well I think both approaches are correct but the choice depends on mostly what you already have in place on the server side and if you are planing to use the same functionality from different apps like (Android,iOS, Windows Phone apps). In that case it makes sense to just get user token with permissions you require on the front end and let the web server talk to facebook using that token. You could even save this token for the user so they don't have to give permissions again if for example you have web registration and app registration. In our app we are using this approach since there are basically five front ends (Android,iOS, Desktop,Mobile Web,Full Web) this way application developers just get token using sdk on there platform (you have to use tokens and not user name, password because of facebook rules for security). On the other hand if all Facebook communication is used only inside your app and the server doesn't need to know much about it put api calls in the app.
In my opinion, it is best to use the available SDKs/APIs for each given platform instead of trying to write your own centralization and use a single library. Since you are specifically interested in how the Android app should handle social interactions, I suggest using the Facebook SDK for Android.
While it does increase the size of the code you must maintain and the SDKs/APIs you must learn as your list of platforms increases, the most important factor for this approach is the user experience. By sticking with the native libraries, and growing your app as those libraries evolve, you will be providing your users with an experience that they are most likely to be used to. They won't have to learn how to use your app, but will be able to make posts, update their status, and look at their friend list using controls that they are accustomed to using. Additionally, you will be able to take advantage of specific platform functionality (in the mobile case, such as having your app post to a users feed in a way that promotes your app: https://developers.facebook.com/docs/tutorials/androidsdk/3.0/games/feed/)
I am writing a basic app that interacts with a webservice I'm writing using AppEngine. I was wondering what the repercussions are of using login based authentication and managing users individually on the server side.
I know the business benefits of knowing your users and since I plan to eventually have some user generated content in the service, I realize I will eventually have to add it.
Right now, I'm concerned more about the technical aspects of adding this feature. What are the development and maintenance costs of adding these services right now versus adding them at a later point in time i.e. when the datastore is already populated with some 'anonymous' data and not user histories are kept ?
I know this is a vague question so I'll try to quantize the situation. Let's say we have an app that allows users to search the surrounding area for restaurants. The app only needs to send to the service the type of restaurant, say 'Chinese' ? The app is popular and gets a 100k users. Now we want to add a favorites system. Would we have been better off adding it from the start or is it better to wait to get some user and then add features ?
An underlying concept here is also the value that users attribute to a personalized experience and it would be great to get some insights from experienced App developers.
It seems feasible to build your system from the ground up using an internal unique identifier to segment user data. To start, just use the device's unique identifier to authenticate, then add a login-based scheme later.
I recently rolled my own api-based authentication system using GAE, and one of my biggest regrets has been not biting the bullet and doing it sooner. That said, if the context warrants (ie you want to test out a concept and see how well it resonates), I'd say you are safe going with an extendable approach, like the one I've described.