Can anybody please explain me what is the difference between cocos2d-android and cocos2d-android-1? What are the functionalities differ between them? And the related details.. I was searching, but not yet get anything appropriate to it..
The main difference is that cocos2d-android is basically dead, or at least it has had no activity since November 16, 2010.
The cocos2d-android-1 branch was created because of a lack of activity in the cocos2d-android version. The code is hosted on github and the commit log shows at least a few commits per months. It's not as frequently updated as one would hope it to be, but it's better than nothing.
Unfortunately both versions are still based on cocos2d-iphone 0.99.4 which was released in July 2010. So if you absolutely want to develop Android apps in Java, use cocos2d-android-1. If Java is not a deciding factor for you, then cocos2d-x (C++) will be the better choice since it is frequently updated and has financial backing.
Related
An application I'm working on was broken by an iOS non-retrocompatible update. It had a big impact on our client's business before we could fix it.
So I'm trying to find a way to anticipate breaking changes in iOS and Android updates.
I've already found:
Apple technical publications: https://developer.apple.com/library/content/navigation/
Android behavior changes:
https://developer.android.com/preview/behavior-changes.html
But it's a lot of reading and I want to make sure every developer in my company knows everything there is to know about breaking changes and that they learn about it as soon as the information is available.
How do you do this kind of technical watch ?
How do you go straight to the useful information ?
Do you know any website or newsletter that might help ?
Thank you a lot for your help.
Update-breaking changes in iOS are rare. That having been said, a few observations:
When there are breaking changes, it's usually in stuff about which Apple has given us ample warning. E.g.,
Apple has started to enforce long-standing counsel about making writing thread-safe code, making sure that certain tasks must happen on the main thread, etc.
Likewise, the shift from 32-bit to 64-bit code base was something that Apple warned us about years in advance.
When Apple says something is "best practice", it's sometimes because they know that failure to do so can result in breaking changes at some future date (usually years down the line). E.g. Apple has advised autosizing masks well before new screen sizes came along. They were advising autolayout and size categories well before split screen multi-tasking was released. Etc.
If they say something is "best practice", they're often trying to help you future-proof your product.
Where possible, stay in the highest possible abstraction in your code. The lower level you implemented your code, the more likely it is to not gracefully handle changes you didn't anticipate. The higher-level the API is, the more likely Apple has taken care of ensuring a graceful transition.
Avoid relying upon undocumented behavior. And definitely avoid anything in direct contravention to the existing docs. (I know it sounds crazy, but there are all sorts of situations where documentation warns you about not doing something even though you might discover empirically that you can get around it.)
Bottom line, if you've empirically discovered some cute technique that isn't documented anywhere, that can easily break. If it's not formally outlined in the documentation, the more likely the behavior is to result in breaking changes.
Watching the "What's New in ..." WWDC videos is a great way to not only discover what's new in every release, but there's often parenthetical remarks about "if you used to do x, consider doing y." Heed those warnings.
I think the WWDC videos are must watch for everyone (esp the high-level "What's New" videos), but if that's too much for your team, divide them up among the team and then reconvene the group and have each person give a 5 minute précis on what's critical.
Every time there is a new release, you should review the release notes, e.g. these should redirect you to the latest docs:
iOS: http://developer.apple.com/go/?id=ios-sdk-release-notes.
Xcode: http://developer.apple.com/go/?id=xcode-release-notes.
The signal-to-noise ratio in these docs can be a bit low, but generally important stuff is covered in here.
Listen to the compiler:
If API has been deprecated, the compiler will warn you. Deprecated API is at risk of being formally removed in future release. If you need deprecated API to support devices running older OS versions, then add run-time version checks, using the API most appropriate for that OS version.
Be wary about disabling compiler warnings. It's quite easy to disregard compiler warnings, or worse, silencing them. If there are any warnings that have been silenced, not only turn them back on, but treat them as errors.
A couple tips for Android development:
Monitor and address deprecation warnings in your build. This is generally a good practice, but especially important on Android. Deprecated methods are an indication that an API will be retired in a future version of the platform. Often this could be an indication that you will soon have to re-write a component in your application.
Make use of the Android support library. This will allow you to implement functionality requiring newer API levels on devices that are not yet at that level. This allows you to code to newer APIs thus helping to future-proof you app.
This is a far-from-complete list. For a much more in-depth overview of this topic see: https://developer.android.com/training/basics/supporting-devices/platforms.html
I know that my question is quite generic and maybe there is more than one approaches to take that decision. But I would like to listen different approaches that maybe I haven't thought since now.
Also, forgive me if stack overflow is not the right place for questions like this (since it is not technical and specific) but I strongly believe that there is not more appropriate place for this question than here. Also I am pretty sure that this subject may be interesting for many android developers here.
So, when I have to make that call, first of all
I consider the official statistics of each distribution. So, I take a look in diagrams like this. Of course we have to keep an eye to the market and to consider very seriously what will be the future of our app one or two years later
A second factor can be the api restrictions, but if you face this problem, sometimes is easier to decide.
Least but not last is the specific market statistics and trends. For instance if the app is paid then you go to more specific statistics, for example Android L users spend more money on google play than the older version users.
All these thoughts became more strong after the release of Android L which is in my opinion the most competitive version against apple. Android L encourages the use of Material Design , contains cool animations and ifrom the point of view of speed , memory management and more technical stuff is way better than the older versions (as it supposed to be).
Thank you
All my apps are currently using api 15+.
Facebook SDK is supporting 15+ api too.
I would use api below 15 just if needed, you have more support and more easy methods to implement your app with 15+.
Well you definitely should install Android Studio and create new project in it. There will be a dialog, which will help you choose a version, giving a percentage of covered devices worldwide.
Can I create android app using Ceylon? Since Ceylon can run of any JVM, the implementation of Ceylon to create android app should be pretty simple as far as I understand. Is it like Scala where the size of App becomes considerably larger and have to use proguard or SBT-android plugin? How viable is it? Can Ceylon be good option for this? If yes, can somebody point me to the proper direction?
Seems that Chochos' answer is a bit outdated. Here you can see that the Ceylon team has already published (January 2014) some initial Android support, even with an Eclipse plugin.
Another older thread that talks about this is this one. It would be great if during these 7 months of 2014 they have ironed out most of the kinks, and writing Android apps with Ceylon is already a pleasure. I myself will test this ASAP.
UPDATE: There's a "Ceylon-Android" compatibility plugin that one can install.
Writing Android apps in Ceylon is a long-term goal, not a priority at the moment. So at least for the remaining of 2012 I think the answer will be No, you can't write an Android app in Ceylon.
Hi there Im new to mobile application development. I had developed Android apps using Java and is just starting to get the hang of Cocoa Touch and Objective C. Now I am curious on mobile web application development to create cross platform/device applications which would at least run on Android and iOS(Apple devices: iphone, ipad). I tried Titanium and developing applications with this framework seems very promising. Although it is very powerful, popular, mature, documented and very easy to learn I had doubts investing time and to commit on using this framework for my projects after reading this blog which many Titanium users seems to agree with Why you should stay away from appcelerators titanium.
It seems that release v1.6 sdk and v1.7 sdk have the issue which they describe, the negative comments stopped right after the v1.8 sdk release was out.
My question is, is Titanium v1.8 sdk free from the memory starvation issue and other issues which were discussed on the blog post?
Would you personally recommend this for production use? And by the way I am using the 1.0.7.201112152014 Titanium build does this use the 1.8 sdk? Thanks in advance.
Take a close look at the progress of comments. It starts from people agreeing with him, and in the end everyone disagrees.
You can select the SDK you wish in the tiapp.xml editor, which is embedded in Titanium Studio. You should indeed use 1.8.x
The platform isn't, and probably never will be, memory issue free. But it also depends on how you build your app.
Stay away as much as you can from includes. And also stay away from creating a window/view/etc. with a file as url in it, this causes most memory issues because it's in a different space.
If you code well, you can use it perfectly without any issues.
Blog post author here. I don't fully agree with Topener - go ahead and read the comments yourself, it's just not true that "in the end everyone disagrees".
For what's worth: my experience is related to version 1.6.2. I've talked to people working with trunk and they told me that the memory issues are far from being resolved.
The only approach that seems to work is, as mentioned in the comments, the Tweetanium approach. But beware, that's not "if you code well". It's "if you code the way Titanium likes". If you take a look at Tweetanium (I suggest you to do it no matter what you decide to do in the end) you'll see that it has a very specific way to deal with architecture. If you follow that path, you should be good. If you think that the way Tweetanium is structured is good for you application, go for it. Be wary though, because (at least in what I consider to be complex) Tweetanium is not very complex, and with growing complexity I found that their approach is difficult to maintain. Again, evaluate for yourself.
Then there's the Android issue. Android support is far from optimal - Wunderlist decided to rewrite their Android version in native, I myself have had huge problems in making anything even remotely complex in iOS working decently on Android. If you need to support only iOS it's alright but, if that's the case, I don't see why you shouldn't write the app directly in Objective-C... considering also the (unavoidable) delay/mismatch between the Titanium and the iOS SDK.
Just my 2c. I suggest you not to take the decision lightly - it costed us a lot.
Is "AndroidAnnotations" reliable? I've searched it but couldn't find many articles on it(reviews or tutorials).
I've been considering using this library in my project which already has quite lots of users. Before adopting it, I need a good reputation on it. So my concerns mainly are,
Are there famous products using this library?
Can I say it's stable enough to adopt it for my big project?
Will it be maintained well? (bug fixes, etc)
Thanks in advance.
I am the lead developer of AndroidAnnotations. Let's answer your questions:
Can you rely on AndroidAnnotations?
I think so. AndroidAnnotations is a compile time framework which generates code. The generated code is readable java code, which means that if you need to understand what happens, you can. No magic happening at runtime => you are in control.
We try to maintain a list of external articles / tutorials here.
Are there famous products using this library?
Let's be honest: I don't know. Matthias Kaeppler from Qype talked about AndroidAnnotations at DroidCon London 2011. The frontpage lists the applications that we know for sure are using it. I know there are way more people using it because they ask for enhancements and report bugs, but they usually don't let us know when they publish an app. And of course, the idea of "writing clean and maintainable Android code" is not yet very common in the Android community.
Can I say it's stable enough to adopt it for my big project?
We are using it in our own apps, and we find it perfectly stable. So I would answer yes, but I think you should just try it :-) . Download the 2.2 RC2 (will be released stable soon), follow the instructions and see for yourself. You can do progressive enhancement, and start enhancing only one or two activities. See how it fits you, and let us know if anything goes wrong. And if you do release an app with AndroidAnnotations on the Android market, please let us know, we'll update the front page.
Will AndroidAnnotations be maintained?
Yes, it will. Although it started as a personal project, AndroidAnnotations is now sponsored by a company, eBusiness Information. This company employs people (including me) to work on AndroidAnnotations, with the aim of making it a major Open Source Android framework.
As you can see here and there, we are adding a lot of new features for the 2.2 release. And you won't find a lot of open Defects in the issues, because we concentrate on fixing any bug before adding new features.