I'm developing some standalone games but not online ones and really want to include in-app purchases for some items. I'm using Unity3D for Android platforms, so most of my code is written in C# and Java.
I know well there's no way to protect the code written in C# and Java from reverse engineering at all. Just in case, I searched for some in-app billing security guidelines but those didn't seem to be effective for standalone Android apps. If I was developing online games, then yes, I could try some ways to prevent from cracking, because the game can't be played without a server connection.
But that's not my case.
Even if I use super safe APIs in the world for server-side verification and revocability, there are always possibilities for crackers to decompile and modify the code to skip reaching the store or server and just return true.
Then they can pack it again as APK and play with no limitations. I also tried to write some important code in unmanaged C++ and use them in C#, but I quit it soon, because I thought it's also easy for crackers to break the connections between C++ and C#.
I've already said to myself there's no real solution for this. That's why I've never tried to put the in-app billing system yet.
But still wonder if there is anyway to make crackers harder to change the code for in-app billing, aside from real basic skills such as obfuscation.
Related
So I'm looking to make my own not so smart "smart" watch Bluetooth device. From what I've found online, I will need some sort of "brain", a thing capable of using BLE, and since I want a display, also an led screen. I need to display the time, and be notified when a call or text is received.
My question comes down to these 3 points-
What should I use/buy for the brain? I'm assuming some sort or variant of a little cpu? I'm also going to need the Bluetooth side of it, but I'm unsure of what I would need that is capable of giving BLE to my device.
Is it possible to make the software side out of this in Java? It is the only language I know extensively, but I'm willing to learn any of it is needed.
Is there anything special I would have to do to pair it with an IPhone (such as make an app, code it a certain way, etc)
I'm sorry if at any point I'm too vague (I don't know enough not to be) or if I'm oblivious to any well known facts; this is my first time ever building an electronic device.
If you would like a smaller cheaper solution and you're somewhat accustomed to working with micro-controllers, I would say look at something like Arduino Micro plus a BLE shield or another brand micro-controller.
Arduino uses its own functional language that's fairly easy to learn coming from java and any other micro-controller would probably use C, if you decide to go that route. A micro-controller would most likely not support java, because the JVM is simply too large and has too much overhead for a tiny cpu.
The time should not be an issue to update via BLE. You can implement the calling and SMS via the ANCS protocol.
Here is a good example/tutorial for an arduino "smartwatch".
I want to develop a navigation app like "Find my Car" or something. For the navigation and the map i want to use the google maps api.
Now i must decide, which language i want to use. Java vs. HTML5.
I'm more familiar with Java, but in the Google Maps API documentation, it would be easier to develop with HTML5, is it?
The application must run on a android phone. So what is better to use: Java, which i'm more familiar, or with HTML5, which (i think) is easier to use in combination with Google Maps.
Hope you can help me, i must decide me in approximately one hour.
Generally, I would not say that the answer is always Java. It actually depends on your needs, like always.
The great thing when you use HTML5 (you could try PhoneGap: http://phonegap.com/) is that it will work on multiple different systems, whereas a native Android app won't.
On the other hand, in a native App, you will be able to access to the whole Android API, and it will be more powerful as well.
As a conclusion, if you need a powerful app processing images in real time, you want a native application. But if you want something simple that could easily be rendered in HTML5 and you potentially will create the same application on a different system (say, IOS), then HTML5 will make you earn precious time.
And in the case where there is not a clear "good" way to follow, simply choose the one in which you are more comfortable: as long as you can create an application that answer your needs, it will be the most productive way.
And always keep in mind that it is possible to include a "WebView" in an Android native app, which means that you can have best of both worlds.
In your very situation, it seems that Android already has some nice features for using Maps (most probably better than the HTML5 version). That might help your decision.
if you're developing an app (not game) in Android the answer is always Java! Always!
and implementing maps in Android in its native Java is as simple as 1.2.3 https://developers.google.com/maps/documentation/android/
Language, IDE, platform ... everything is tool. What will you use depend on the needs of your application. I work with both techniques. When you'll develop an application that uses many resources linked to hardware (eg accelerometer, gps...), it is advisable that you use a native language, it saves battery and you has the maximum advantage of the device, gaining in performance.
Now if you'll develop an application that uses few hardware resources, the most interesting solution is HTML5 (example: PhoneGap, SenchaTouch, Titanium, etc..).
In my years of experience, before deciding how to develop I wonder what I will develop, so as to see which one best meets my need!
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 8 years ago.
Improve this question
I've just finished a relatively large project for the Android, and it's left a bitter taste in my mouth with the knowledge that it will never run on one of the most ubiquitous handsets this side of the solar system (the one by that fruity little club).
So, for my next project, I want to write it in a way that makes most of the components easily transportable between the iPhone and Android platforms. The way I'm thinking of doing this is by coding most of it in Objective-C, and then adding the platform-specific parts in more Objective-C and Java respectively. On the Android side, this will require using the the NDK.
My knowledge of C is good, but my knowledge of Objective-C is close to zero, and I have no desire to learn C++. How sane is the approach above, and is there a better one? Is there any way I can code in Java and still reach the un-hacked iPhone market? And how likely is it that the people I know (iPhone users) will have an Android phone by next year?
Step back and think about what in the end you will logically be able to share.
The UI models are fairly different, the components are different. In the end what you might be able to share is data object classes, possibly some algorithms. It's not even like you could realistically end up sharing network code as in the old days because you aren't directly using sockets, you are using HTTP libraries.
So will all of the effort you are putting into this really find a payoff in the end? It seems to me the end result will be a brittle mess that is hard to update, and is mediocre on both platforms instead of being great on either.
Why are you writing applications? To make life easier for you, or your users?
Others have said basically this, but I'd like to make it more explicit. Your best bet is probably to write:
Cross-platform data models & core logic, using:
bits of GNUstep (Obj-C), or
CF-Lite (C), or
Whatever you'd like, as long as it's cross-platform :P
iPhone-only interface code, using Cocoa Touch (Obj-C)
Android-only interface code, however they do it for the Android.
That's as close as you can get; any attempt to write cross-platform interface code will undoubtedly result in a mediocre app on both platforms. But making all the rest of your code portable and just wrapping a device-specific interface around it is done all the time and has been worked great for some iPhone developers.
Objective-C without Cocoa is not so useful and won't bring you much closer to haveing a working iPhone codebase. You'd probably be better off writing your core in C with Core Foundation and using either Java or Objective-C for the platform specific parts. Apple has open sourced a large chunk of Core Foundation as CF-Lite, and it's toll-free bridged with Cocoa on OS X (i.e. you can use many CF classes interchangeably with their Cocoa counterparts).
My guess, which has no experience to back it up, is that you probably could write Obj-C with Google's NDK somehow, given that GCC exists for ARM, is open source, has an Obj-C compiler and a basic Obj-C runtime (which if it doesn't already probably could be hacked up to work on a new architecture), etc.
That might also be a lot of work for questionable benefit.
And of course "Obj-C" (without the NS classes) means something very different than "Cocoa", which is what most people really mean when they say "Obj-C". You might be able to re-use some of GNUstep for some that, but... Honestly, I doubt it. Sounds again like a lot of work.
So, yes, I think it is possible. It's also a lot of work and I don't think it's worth it.
Given what you've said, if I were attempting this, I would be tempted to write as much of your core logic as possible in C, then wrap it with two separate GUIs for each platform.
Coming at this from a different angle... I know that you said you wanted to try and stick with Java, but if you know C# then you could go with the MonoTouch framework for the iPhone. Mono is essentially and open source implementation of the .Net stack. The Mono team is working on bringing Mono to the Android so you could basically write a shared C# library for your business logic and have different Views/Controllers per platform. This would all be in C# of course and it is a bit more expensive, but it does solve the problem of writing everything in different languages.
I believe it is called MonoTouch on the iPhone and MonoDroid on Android.
The Apportable SDK is an Objective-C approach to write once and deploy to both IOS and Android. It will cross-compile a running IOS Xcode project to an Android SDK.
See here for sample apps that run on both platforms in minutes after download.
I'm not sure about Android but with the iPhone you can essentially write straight C as long as you wrap it up in Objective-C classes.
The Objective-C runtime has not been ported to Android yet. It shouldn't be too much work, but still, without a working knowledge of the language I doubt you'll have an easy time porting it.
What you are trying to do is going to be hard for a generic application, but should be possible for games, if you choose to develop the game in plain C (which is supported by both the Android NDK and the iPhone). You'd have to write up some glue code to pass input events from the Obj-C and Java environments into your C code, but that shouldn't be much of a problem - Objective-C allows you to directly call into your C code and there are plenty of example projects which do exactly this for Android.
I haven't tried this myself or finished watching the talk yet, but there is a Google Tech Talk on Developing iPhone Applications using Java up on YouTube that looks pretty promising.
XMLVM is a project which is capable of translating (some) Android applications to the iPhone. For more infromation, visit http://xmlvm.org/android/
I realize this may be a tad late, but it seems the industry is going in the direction of web apps these days to achieve app portability. That is, embedding a web-browser in your "skeleton native app", and writing javascript, css and html for Android, iOS and the other major smartphone platforms.
There are tools that help you with this. You might want to check out PhoneGap and Sencha Touch, but there are many more. Note that this approach may not be ideal for real-time/animation-intensive apps.
Here is a talk from facebook's mobile # scale conference where two teams (dropbox and orchestra) used similar approaches. Dropbox used C++ to create libdropbox and Orchestra (mailbox) used Objective-c to create libmailbox.
Again, they wrote their front ends in the platform native language and used their cross platform libs for core logic and data.
Key benefits I took away: Mailbox went from ios to android in 5 weeks because it was just building UI code. Dropbox can beta test changes to core functionality that are in the shared library with Android beta deployments were it's easier to do massive deploys at scale for beta builds.
If you can wait until later this year (exact amount of time unknown), Adobe will have AIR for Android and a compiler to iPhone. Thus you can write an app in AIR for the Android and use most of the same code to compile to the iPhone.
http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/
Even if you can't wait see: http://www.insideria.com/2008/12/actionscript-to-cocoa---protot.html where it explains the similarities between ActionScript and Cocoa.
Also check out: http://labs.adobe.com/technologies/air2/ for the AIR version capable of using the touch screen.
So you can soon write once and deploy to Android and iPhone using ActionScript 3.
I know Java apps can be run in Android. But what I want to know is this: I have a perfectly normal Java app and I want to port it to an android platform. What changes would I need to do to my app in terms of GUI and other code to make it usable in Android? I know Android uses XML file to control the look and feel of its app. So would I need to change my GUI completely?
I just want to know the general overview of how porting may be done. If anyone could point me to right resources, that would be great. Also, for your info I'm a newbie to developing android app, so please be patient with me :)
Update: Both very helpful answers. Thank you!
The short answer is that you would simply rewrite all of the GUI from scratch, for Android. It simply uses a completely different UI framework. While basically all of the core Java libraries are there, Swing and AWT libraries are not.
If you are looking to translate parts of it automatically, I don't think there is any such tool. You're going to be building a brand new Android GUI.
And really, that makes sense. These frameworks are serving reasonably different platforms and needs (desktop vs. phone). You probably need to be redesigning your app quite a bit to go from a desktop to a phone.
Good news is the non-GUI parts ought to work as-is with no changes, unless they do something unusual. You may have to package third party libraries into your project if they are used by your code.
I expect that it will be a great deal of work to do the porting, as the way that your application works with Android will be different.
You will also have some issues, perhaps, with the fact that not everything in java is supported, as it is a mobile device, but does more than JavaME.
It would help if you could explain a bit about the application, as how much it needs to interact with the user or any other resources on the device will determine how to port and how much work is involved.
Your best bet though is to see about learning to program on the Android, and there are several good books on the subject. I got one from Manning publications that I found helpful.
You may want to look at the comments in this article, as I think it would be a good starting point for you on what may need to be changed:
http://www.anddev.org/problem_in_android_project_conversion-t1633.html
My friend and I are planning to build a simple chat client to let people in a (physical, real world) room chat with each other (people chatting over the same wifi network, possibly pinging some external server to organize things by the external IP address of the wifi network). Partly we planned this as a chance to play around with Groovy, which we haven't done much with. But then I thought - damn, how many people have the Java 1.5 runtime? Maybe this is kind of thing where Flash would be better (when I say "Flash" I mean "Flex")? I hate ActionScript and I have very little experience with it, and I've no real interest in using it, but I'm thinking, if we want 9 out of 10 of our friends to be able to use our software, Java is possibly not the way to go?
My concern is in particular with the demographic we have in mind, which will tend to be freelancers and artists and individuals, rather than people at work. I'm aware that Java still has a decent overall market share, but I'm under the impression that its use is heavily concentrated in the computers that people use at work. Folks who don't work at corporations may not have a modern runtime?
I then decided to look up Java market share. It is surprisingly hard to track down info about specific JREs.
There was this on stackOverflow, but its focus is on RIAs, which isn't what I'm talking about:
What's all this business about Flash, Flex, Adobe Air, Java FX and Silverlight?
And then conversations like this make it sound like Flash is the only reasonable choice to make if you want people to be able to use your software without jumping through a lot of hoops:
http://forums.java.net/jive/thread.jspa?messageID=317749&tstart=0
This seemed like a reasonable summary of Java versus Flash issues:
Client Java vs (Adobe) Flash for web applications, what to choose and when
I found it surprisingly hard to track down actual market share data on particular JREs. And I found no easy way to find out if folks who with modern JREs installed are mostly using their computers at work.
So I'm open to hearing some anecdotal information here. If we built our simple chat client in Groovy/Swing, would our target demographic be able to use it? Is Flash the only reliable way to go here?
If portability is your goal, why not go for a JS only approach, perhaps using one of the COMET styles of push? Here's an article to learn more:
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications
If a JS RIA isn't what your after. Then Flash/Flex are your next best bet. I'm usually biased towards Java as a technology, but based on your target app and audience I think you'll get more joy using a Flash-based technology.
Adobe understand RIAs better than Sun, which was kinda demonstrated by some high profile Java 2D devs moving to Adobe in 2008/09. Plus with recent Flash Player developments you'll get your app onto more mobile devices.
Obviously server-side in Java ;-)