I plan to go with the free version in order to promote the paid version.
Few questions:
In your experience, is it helps?
After a user has installed the free version, if he wants to install the paid version,
he needs to remove the free version first ?
how it effects downloads rates ?
What is the correct way to do it?
After some research for one of my applications, I have found the following options:
1 - Have all your code in one big library then make two applications using this shared library and have them toggle some flag saying the application is in trial or full mode.
To me, not very nice, because you'll need to handle the fact that the user can have both the free and full applications installed, when the users gets the full application, you'll need to move his data from the trial version to the full version (databases cannot be shared easily)
2 - Have one single application that can be unlocked by buying a code on a particular website
Good thing is you can provide alternate payment options (paypal, ...) and also avoid being limited to the Android Market. Can be nice when dealing with countries that don't have access to it.
3 - Have a single application with all the code plus one small unlock application to unlock the free application limitations
Good thing is you just need to update the free application and all users will get bug corrections. You also take advantage of the Android Market. Downside, is that your users need access to the market to get the full application.
I have personally chosen option 3 but I will add on top of it the option 2 because I intend to distribute my application on countries/devices that do not have access to Android Market
Edit 2/2/2011: I have published an article about that on our website. Your can read it there: http://www.marvinlabs.com/2011/01/sharing-code-full-lite-versions-application/
It's always a good idea to provide a demo (assuming there is incentive to buy the paid version, like a time trial, feature cripple, whatever is best to demonstrate the app without ruining the experience).
Add two versions of your app to the market, one free, one paid.
No, since they're two separate apps, but it would make sense to remove the free one in order to not have two apps installed.
They're two separate apps, so they have two separate counts.
As an alternative, you could use a keyfile to unlock the features of the full version. If you do that, you should probably use Google Checkout for processing (all "fees" must go through Google's processing as per the TOS, IIRC). There's a lot more involved if you go this route (especially coming up with a keyfile system that cannot be easily hacked).
Related
Google Drive Android API
Google-Api-Java-Client
Requirement:
Single Unique folder which can be accessed(read/write/edit/sync) by multiple applications(Android/ios/web)
Get Images and their thumbnails from a folder to show in a ListView with Pagination.
Because I was told that the Android API doesn't support most of the functionality, from here
I'll try to answer by pointing out the missing functions in GDAA compared to REST(ful). REST has full functionality and will do everything you require. But you have to manage the synchronization yourself (polling, messaging ...).
GDAA is supposed to handle the synchronization and off-line status by means of notifications, but there are significant delays governed by GDAA internal logic (SO 23073474). Other parts that are missing are:
delete/ trash
thumbnails
fulltext search ...
and full bunch of quirks that make it's use challenging. Just look at my question history.
The biggest shortcoming for your intended implementation is the fact, that status of files modified by other apps/devices in Drive is reported with a significant delay, detection of trashed/deleted files by other apps is totally unreliable. Also, you can't get the 's220' thumbnails from GDAA, you would have to get full size files and shrink it yourself, making GDAA useless for preview list of thumbnails. My implementation of a basic Create, Retrieve, Update, Delete (CRUD) app ended up as a messy combination of RESTful Api tangled with GDAA.
Also, I have to point out that the GDAA support team listed here is totally silent with the only exception of Cheryl Simon (who is not officially the team member). So there is no support or accountability. Sorry for the rant.
If the (1) doesn't meet your needs, use (2).
2) is the "master" API, that exposes all of the Drive metadata. It is a REST API so you need to be online to use it.
1) is a local API to allow you to read and write files in the Drive-sync area of your Android device. This can be used when you are offline, and changes will subsequently sync to Drive automagically.
So they are for slightly different purposes. Choose whichever one best suits your requirements.
I found a lot of discussions around this point but speaking either of a Java program running from the jar (in this case it is easy to replace it) or a C# application (I do not have knowledge on C#).
I use a tool (install4j, ..) to generate an installable file for Windows from the jar of my java swing application. My product installed and running on Windows should be able to "auto-update" itself, so I must have a component in my application that checks online if a newer version was to download and put in place of the currently executing.
I do not know how my application is installed in Windows (where are put the files? in one place? ... ) So what can I do to replace the current version being run with a new version (probably from a new installable file télchargé in this case) ? what's the best way?
how can I hide the questions like "do you accept ...?" and keep the original configuration during the update?
The problem for me is that my client wants/does not necessarily install java
Use the Deployment Toolkit Script to ensure the client has a suitable minimum version of Java installed. Then deploy it using Java Web Start to provide auto-update. I realize you don't want to make the client install Java, but you might be making the client install Windows if you make an executable. You'll typically lose more users by forcing them to install Windows, than by forcing them to install Java.
Now, when I give this advice to some people, they say words to the effect:
But my client only uses Windows OS! It will never be run on Mac OS or Linux/Unix.
And to that I would point out:
OK fine, but it seems yo are trying to make a left-hand turn at a right turn only intersection. If you need to turn left, you should have done that 6 blocks back.
What I mean by that is: Windows has its own languages and IDEs specialized for Windows. Being a language designed for Windows would mean it has:
Better ways to delve into the OS. Java keeps its functionality to a core set of functions that can be reliably supported across all major platforms. Anything beyond that requires native code.
Faster development time for any GUI elements. Java GUIs need to be designed using layout managers which are harder to learn and not conducive to Drag-and-Drop GUI design, which can be much faster.
A Windows based language probably has a slew of APIs and tools for providing auto-update, or if not, more free or reasonably priced 3rd party APIs for that.
..there are customers who imposed to not install java..
There is something you don't seem to understand. The GNU Compiler for the JavaTM Programming Language compiles code to natives. That is the only way to 'turn a Java app. into an executable. The GNU Compiler..
..supports most of the 1.4 libraries plus some 1.5 additions.
It does not even claim to support all of Java 1.3.
There are other utilities to install Java apps. with a private JRE. It might seem the JRE installation is invisible to the average user. But the power user would not be fooled. E.G.
Look and Feel
A Swing based app. using the Native Pluggable Look and Feel might look 'much like' a Windows app., but many people can still tell the difference. Swing does particular components differently to native Windows components (most notably JFileChooser, but there are others), and although the rest of the components look a lot like Windows equivalents, they are not exactly the same. Even the AWT based FileDialog looks different to the Windows file dialog.
Security
If the user has a problem with their PC and decides to kill a misbehaving app. they might type the following command sequence to bring up the Task Manager: Ctrl Alt Del
Even most non-power users know that key combo.
Now, let's say I am a potential customer that thinks 'Java is insecure - I don't want it on my PC'. Your app. comes along, I look at the box, no mention of Java. Good so far. Look at the one or two screenshots of it on the back of the box - looks much like a Windows app., OK.
So I fork out $24.95 for it.
I get it back to the office, install it and run, thinking:
It has an odd feel to it, but I'm too busy now, I'll check it out later.
Then I go surfing off to the net, visit a site infected with malware, and that malware causes MS Word to lock up. So I go to kill MS Word in preparation for restarting it, but.. As I'm scrolling down the available processes I notice.. Java is running.
What the huh..?
I immediately kill every Java process and see.. your app. drop off screen.
Let's go even further to assume the Malware (that is still running) goes on to cause $2000 damage to my hardware & wipes the client database I spent 3 years putting together ($50,000 loss).
I would get on the phone immediately to my lawyer and take you to court, suing you for the sum total of $1,052,024.95.
Later, in court:
Judge: What is the million collars for?
Me: Mental stress, your honor. The defendant lied to me and now I have become paranoid. Since that malware was installed, I've lost my business, my home, my wife and my peace of mind. It has caused me to become deeply depressed and I am experiencing suicidal thoughts.
Who do you think the judge is going to side with? Do you really think you can prove that your app. was in no way responsible for the problem?
Sure, you can put a disclaimer on the box:
No claims of responsibility, use at own risk.
But there are any number of US states as well as other entire countries, that will toss that entire End User Lisense Agreement right out the window and hold you responsible.
What I'm getting at, is that you are taking a huge legal risk to pretend that a Java app. is anything but a Java app. So don't do that!
I am also very keen to know that, as per my knowledge, I deployed my application using JNLP (java network launch protocol) after signing your jar file, Client's jar itself replace with the newer version.
The confirmation question "Do you Accept" in JNLP is because of the certificate windows security and JVM certification didn't recognize that.
here is tutorial for JNLP
http://www.mkyong.com/java/java-web-start-jnlp-tutorial-unofficial-guide/
Is there a good source of data for the install percentages of popular plugins?
No, there is no "good" source for this data. You'll probably be able to find several not-so-good sources for browser statistics, including plugins, but such statistics suffer from several problems.
One major problem is Selection Bias. Anyone collecting and sharing statistics can only collect data from the browsers that visit their site. An example is browser share; more technical sites report a higher percentage market share for Firefox when compared to more general sites. That's because the more technical people use Firefox more than others, and they are the people most likely to visit the technical site.
An example for Unity - Linux users are much less likely to visit a site that uses the Unity plugin because there isn't one for Linux, so you're not counting true share of people that have the Unity plugin installed.
Kdoto's links are fine for getting a basic idea of usage, but any statistics are likely to overstate the percentage-of-users-with-X — if you decide "I can live with excluding 5% of the users that don't have X" you are really excluding a higher percentage than that.
For flash:
http://www.adobe.com/products/player_census/flashplayer/
and:
http://www.adobe.com/products/player_census/flashplayer/PC.html
Note that talks about PCs, and therefore omits devices like phones.
For Unity, have a look at this:
http://forum.unity3d.com/threads/39362-Web-player-adoption
There are 1 or 2 billion internet users, and a little over 1 billion internet enabled PCs. There are only a few dozen million unity plugin users (maybe ~20 million). It's difficult to interpret that data without some context for what you're trying to understand.
The Unity plugin allows you to create things that the Flash plugin cannot easily create, if at all.
Which plugin you want to use, depends greatly on what type of application you want to build.
Minecraft runs in Java in a browser. It would be difficult to build the same application in Flash (and see it run efficiently enough).
I know it is quite old entry but thought of adding something in as I did spent some time researching the topic.
Some statistics can be checked directly on Unity or Flash website so comparing those is not difficult but if you would like to know how many facebook or twitter users has plugin installed it gets bit more complicated.
If you are about to make a decision whether you should build your game to flash or just web player you might want to read: Unity games and Facebook which is 3rd part of the Game Development with Unity3d and Facebook series.
I'm trying my hand in the food industry. I'm going to be developing my epos system in house. All the fancy touch screen systems cost an arm and a leg. I was wondering what are my options if I wanted to integrate a chip and pin device as well? Could I use something like paypal? I doubt supermarkets use such a system though.
Have you considered Openbravo POS? It's great for a basic EPOS system, and has features such as Restaurant Mode (tables etc), as well as reporting facilities etc. It's also free :-)
If you want to use Chip & Pin though, you'll need to write a custom Java module to compile into Openbravo, to link between whatever software your C&P device provides, and Openbravo itself. I've done this for a custom Openbravo installation, but it is specific to the C&P device provider.
PayPal is an online web payment service provider - this is different to the hardware-based C&P.
Edit you're probably also better off talking to your bank about their options regarding C&P - they may be able to offer you such a service, or recommend a partner to lease you the hardware and provide support etc.
Ocius for PC, is a pre-approved chip and pin solution from Commidea, which you can integrate with your software. You will need to have your integration tested by Commidea before you can deploy to any live sites.
Changing your software to work with Ocius should take a few days of coding and testing.
YESpay also offer chip and pin solutions, but I have no experience with them.
I would suggest ERPLY POS , its also free, usable over WWW and its really nice UI
I'm considering creating a screen reader for Android. My questions are as follows. One how much of the internals of Android are exposed through the Java API? I'm looking for things such as system wide notification when text is displayed, notification of a new application being launched, etc. I'd rather not have to modify the kernel source and only allow my app to run on a developer phone. Two, how much processor and memory are left over on the G1 assuming no applications running? Three assuming average use of applications on the phone how much processor and memory are left?
More info
I'm aware that applications should not be designed to work on a specific phone. I picked the G1 because it's the most popular phone currently running Android that I know of. I am looking for lower end system specs that my program would have to fit in, it may run great on a netbook with Android installed but use to much memory and processor to run on most Android handsets.
Update:
There are now two screen reader projects that use Android 1.6, they can be found at
http://google-opensource.blogspot.com/2009/10/talkback-open-source-screenreader-for.html
http://spiel.thewordnerd.info/
AFAIK, screen content (text, graphics) of other apps will for security reasons not be exposed in Android. Otherwise one could grab contact info or whatever personal information gets displayed and harvest that for malicious purposes. So developers currently cannot create an Android app that speaks the text displayed by another application, nor capture the screen. This situation is different from Microsoft Windows on the PC, where applications can do pretty much anything they like, such that the user must decide for himself whether the source of any given application is trusted.
Sadly, there is still no screen reader for Android on the market, so it would be great if you or someone else could create it, but it looks like only a direct arrangement with Google could provide the level of trust needed in view of the above security limitations. Since Google is actively working on improving the TTS and integrating it into Donut, it would seem a fairly simple extra step for them to create a basic Narrator-like (as in Windows) screen reader, or offer a similar touch-based accessibility solution as with VoiceOver on the iPhone 3G S.
Best regards,
Peter Meijer
The vOICe for Android
http://www.seeingwithsound.com/android.htm
(1) Depends on what you are looking for. You better check for yourself. I am not ware of any assistive technologies in place, but I wasn't looking for them either.
Regarding the two specific capabilities you asked for:
(a) Notifications are part of the API.
(b) I am not aware that you can be notified on applications being started.
(2/3) I don't the general amount of RAM that is available for apps, but I can give you an practical answer. Your app's process will be killed if it tries to grab more than 16MB.
I don't know the exact clock speed, but on the android-dev list it was mentioned that the G1 doesn't run at full speed. The rationale behind it is that among other things more speed would run down the battery much more quickly.
Just another practical matter regarding this question. If you want to discuss the constraints go to the android-dev list.