Tag Info

Hot answers tagged

23

In layman's words: Not all users use all of a company's apps Different users have different needs Why force an user to buy a full package when he/she needs only a part ? (Ok, Google apps are free, but other software maker's aren't.) Having those apps separate makes it possible to be updated separately and, most importantly, sold separately. The fact that ...


13

I think that you can only lose by choosing not to communicate. If you don't plan to implement the feature now, at least suggest users that it is not in the current plan to implement, but might be considered in the future. This would not let users think that it's a feature they can expect soon and will send a message that you are not planning on it either. ...


9

Put together a stock "thank you for your interest" letter that covers the possibilities of a) features you will NEVER implement even if I show up on your doorstep with a bag of gold, b) features you don't PLAN to implement but maybe, and c) features you'd like to implement but can't right now. Send that. Because you ALMOST never know when you might find ...


7

Ideally, you should use such requests as an opportunity to help you and users better understand the application. If you think of it, the very reasons why you prefer to ignore these requests are quite important information and you'd rather have them stored and documented than buried and forgotten deep down in your mind. If a request is ignored because you ...


7

To me, the table on the website you mentioned has a somewhat-naïve representation of these differences. It seems to focus on pushing a native app as the best possible solution because of "browsing speed" and access to device functionality, but this may not always be what you actually want to achieve. They haven't taken into consideration other factors which ...


7

You Can't. You can never verify an entity, any entity, be it a person, hardware client or software client. You can only verify that what they are telling you is correct, then assume honesty. For example, how does Google know it is I'm logging into my Gmail account? They simply ask me for a user name and password, verify that, then assume honesty because ...


6

Users expect a mobile app to perform a single task, or a small set of very related tasks. The mobile platforms that you mention started particularly as phone OS's. Typically users performs many short tasks on their smartphone throughout the day. This is totally different from desktop computers. This short bursted usage pattern has lead to the design of a ...


5

Native applications use Objective C or Java. Web applications use HTML5, CSS3, and Javascript, running in a browser. Native applications may have to be written more than once, to satisfy the native platform's specific demands, such as programming language. Web applications may have limited access to the underlying native platform, and may not perform as ...


4

I'm currently working on a mobile/desktop/distributed app with exactly the same requirements and issues. First of all, these requirements are not inherent to mobile apps per se, but to any disconnected/distributed client-server transactions (parallel programming, multithreading, you get the point). As such they are, of course, typical issues to address in ...


4

You pass username/password to the login method of your RESTful API and it returns access-token. That access token is just some unique (for the system) string. Device stores (persists) that access-token. Each time you send RESTful request to the server you put that access-token in header of HTTP request. Server finds the user by access-token and on success ...


2

PhoneGap is constantly being improved upon, and one aspect of the platform that has continued to see development is initializing a project. As new versions are released, there have been steps taken to automate and make this process easier. In PhoneGap 2.1.0, as you've noted, it appears as if none of the initialization process was automated. The ...


2

First, you mentioned both an API and a database (MySQL). I very much recommend that you use an API and don't try to communicate directly between the databases. That latter route will not scale well at all. One good starting point you should consider is using Apache CouchDB. It is schema-less, based on HTTP and JSON, and has a very good replication ...


2

Three words: Separation Of Concerns Do one thing (and do that good). ;-) And on a sidenote: You can't multitask in a single app without reimplementing either some kind of "window management" or some other crazy logic. Which leads back to my initial statement…


2

I'm sure you're comfortable with dealing with user logins, and with communications over SSL, so I'm going to focus on what I think it the more interesting part of the question: how to ensure that your read-only actions - which do not require the user to be authenticated - are only accepted from your own client apps? Before anything else, there is the ...


2

Most Android devices can install application simply by opening an apk file in the browser. You can use self-signed certificates, so no problem there. It's more difficult with iOS applications. Everything you do there must go through Apple. Apple development site has lots of information about the different ways to do that but mostly it reduces to the ...


2

This question is way too broad to have a definitive answer. Business Analysts make whole careers from this. But to give you an extremely basic answer ... Listen to their ideas. Be humble. You've got to understand why they want this thing. What do they think it will do for them? What problem are they solving? It can be like many questions here: they are ...


2

There are many reasons why making an app has advantages. René said some. The ones I would like to add are : Native feel, touch UI optimizations and better UI frameworks. Existing web pages are not optimized to use on small, touch screens. Also, web technologies make it harder to optimize them for touch. So if you are going to invest into making the website ...


2

Those frameworks offer additional features, most relating to the hardware of the smartphones. Those include: accessing and manipulating hardware functions such as cameras, flashlight, screen brightness, gyroscope, vibration... software access, for example contacts, calendar, phone number, mails, HWID... running in the background, receiving (push) ...


1

I think the other answers are on the right path in encouraging you to correspond with your users. one feature request turned into 7.. Based on this comment, you're not giving users enough feedback on the types of features you are open to. Maybe they want you to expand the capabilities/feature set but you're more concerned with performance and usability ...


1

Sit down together and make a planning. Have 1 meeting (not more) on a regular base (every week) all together to be always updated on the status. Split the application in different subtask and assign a task to everyone. If everyone starts putting hands everywhere it will be a mess. Decide incremental "deliverables": Example: "by day x part y should be ...


1

The main difference seems to be that your code converts error responses into exceptions while your brother simply returns them. I believe that exceptions should be used to indicate programming bugs or emergency situations that threaten the integrity of a piece of the system. From this perspective, the library should probably not throw an exception because ...


1

Yours is better in the fact that you treat your corelib as an API. Throwing meaningful exceptions upwards to the application. His is better for being precautious by encoding the email and password entries. I really don´t see the need of the DepotServiceResult if not to avoid costly exception handling (which in this case should include a boolean property ...


1

Can't say what Google are concerned about, but what I think: Is Google concerned about tight coupling between the apps? - Having the apps together means you can't update them separately. Every minor update in a single (sub)app would result in an update in the app. This means many small updates frequently or few larger updates rarely (which is not good for ...


1

The biggest reason is that smaller teams are more effective at delivering software that customers actually want to use, so you want to use as small a team as possible. You might think "well, why not use small teams for the individual features, and combine them later?" It turns out that combining work from more than one team in a seamless, consistent manner ...


1

I like Phonegap/Cordova (I stuck more with the cordova cli) and would use it again but wouldn't choose it under the following circumstances: Complex HTML-heavy pages - You really want to keep your CSS and HTML as minimal and tidy as possible or things can get messy with swiping, scrollable areas, etc... Webviews are still pretty bleeding edge owing to the ...



Only top voted, non community-wiki answers of a minimum length are eligible