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
Related
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.
I have just been given a task at work to help audit a code base for a mobile app. I am not a mobile app programmer, although I've been a software developer for many years now, but know nothing about mobile apps. I was wondering if there's any tips or tools that I can use for this code audit.
I have seen the replies to this older post for a Java EE application, which can't be applied to my case since they're mostly based on having maven to build the app and in my case they use Gradle. Also these replies are from 2011 and perhaps there are more recent ones I'd really be very grateful to hear about.
In itself, the fact of appointing someone with no experience in the target environment seems like a complete nonsense to me, so I'd question the management here.
I do hope for you that you know at very least the languages these apps are written in: probably Java for Android & Objective-C for iOS (your question didn't mention what technologies your past experience concerned). If not, you're bound to just make remarks about comments, file size, and maybe some about naming conventions, which is of little interest compared to a real audit.
Beyond programming languages, iOS and Android are designed in very different ways, with different conventions & patterns. I actually know very few people who are really good in both environments, and there's a reason for this: these are different worlds, each of which you can easily spend your whole time on to learn APIs, common libraries, design philosophy, work-arounds for common issues, and understand a bit of how the internals work.
I don't know how much time you have to perform this task, but I'd suggest you learn how to code a basic app on the target environment, and learn about the key components.
My approach is generally:
gather some context from the team
get the source
build the app & get a taste of what it's doing (I usually hand-draw a screen flow diagram at this stage, it's useful later when you navigate in the code), also take note of bugs, slow features, non-user-friendly stuff (feedback is important to the team)
go to the source code, examine it's macroscopic layout:
. look at the build scripts to see what external libs it's using
. take note of the general package hierarchy, check that the naming is consistent, that packages are not overloaded with junk
. look generally at the class naming: is it consistent? do class names help figure out what's actually inside
. do some basic stats about file sizes: it's something that can quickly indicate some design flaws
now about the code in itself:
. read it until satisfied that you understand the general way it works (drawing a technical flow diagram helps), I like to start by the app entry-point (generally an activity in Android)
. make sure you spot how what you read achieves what you saw while testing the app
. take note of bad coding habits you spot while reading (naming, comments, it can be anything: there's no limit to how bad the code can be ^^)
. take note of unreadable/overly-complex bits of code (but don't spend days just to understand them)
. if you had noticed slow features in the app, it might be worth looking at those bits of code a little more carefully
. have a good night sleep, then re-read all your notes, and try to extract some high-level remarks about the application design
Now, specifically for Android, here the most common list of things to look for, based on my experience:
components life-cycle handling issues (for components like activities, services, fragments and such): symptoms include device rotation and application switches causing issues
thread handling issues (things done on the UI thread, when they should really run in background)
massive activities / services (many people think that creating activities / fragments / services is all that's required in terms of architecture - it is true only for very simple apps)
I won't enter more into the specifics, because people a lot more intelligent than me wrote books about this. And you have to code apps to really get a grasp of those subjects: a lot of them, so that's what you should start with: code apps yourself, otherwise: 1/ your audit will be irrelevant 2/ the team will spot your lack of skills pretty fast - depending on the aim of this audit, you might have a very hard time facing them...
A coworker and I were talking (after a fashion) about an article I read (HTC permission security risk). Basically, the argument came down to whether or not it was possible to log every action that an application was doing. Then someone (an abstract theroetical person) would go through and see if the app was doing what it was supposed to do and not trying to be all malicious like.
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing. Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
Can I get some input one way or the other? Is it completely impractical to even attempt to log what a foriegn application is doing?
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing.
Not so much "hack Dalvik" but "hack the android.* class library, and perhaps a few other things (e.g., java.net).
Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
You might be able to do some fancy pattern matching or something on the output -- given that you have determined patterns of inappropriate actions. Of course, there is also the small matter of having to manually test the app (to generate the output).
Is it completely impractical to even attempt to log what a foriegn application is doing?
From an SDK app? I damn well hope so.
From a device running a modded firmware with the aforementioned changes? I'd say it is impractical unless you have a fairly decent-sized development team, at which point it is merely expensive.
This is both possible and practical if you are compiling your own ROM. Android is based on Linux and I know several projects like this for Linux, like Linux Trace Toolkit. I also know of research into visualizing the results and detecting malicious apps from the results as well.
Another thing functionality like this is often used for is performance and reliability monitoring. You can read about the DTRACE functionality in Solaris to learn more about how this sort of stuff is used in business rather than academia.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Our company is on the verge of picking between native Android/iPhone development and some cross-platform solution, specifically Marmalade SDK (former Airplay SDK).
We are a computer vision company, meaning we need low level access to the camera devices. Also, our applications are computationally expensive, meaning we tend to squeeze out every little bit of processing power available.
Our team has sufficient experience in both Objective-C and Java (or C) to provide platform specific solutions. However our main focus was always on C++, as such we would like to prevent fragmenting out team and rather work with a cross-platform solution.
Our biggest fear is that choosing Marmalade will either sacrifice processing speed (main concern) or severely increase development time by complicating low level access to camera frame buffer.
So my question is, besides the obvious, what are the advantages, but specifically limitations of Marmalade SDK for processor intensive video processing applications.
I have used Marmalade/Airplay for almost two years now in my indie game company. For me it's a win because I'm just one programmer, and I can do virtually all my work in Windows using MS Dev Studio (which is my favorite dev environment by far) and because it shields me from having to deal with a lot of the platform-specific details, especially with the various development tools, that could eat up a lot of the time I'd rather spend on game content.
Speed will not be an issue with Marmalade. Your C++ code runs natively. Also, access to camera and other functionality should not be much of an issue; it's either already provided or can be added using the extensions SDK, which is pretty straightforward to use.
Marmalade is a mature product and the company is pretty helpful in resolving issues quickly, even for indie developers that are using the product for free. In addition to the cross-platform-ness, it has some nice tools built in, such as a memory leak tracker, a logging system, graphics analysis tools, and others.
There are some downsides that I've experienced with Marmalade.
Even though in theory any API or third-party SDK is accessible through the extensions system, in practice the thing you need may not exist yet. As an example, a number of developers are currently struggling to get the analytics package Flurry integrated, and it's been a challenge for some. The situation is similar with lots of other third-party SDKs; they may be just a couple lines to integrate if you are doing Objective-C development, but can be more difficult via Marmalade.
Some things are less natural because of the cross-platform layer through which you operate. Some examples for me have been:
I've had trouble getting my splash screens (application start-up screens) to display properly in all screen sizes on both iOS and Android. And it's been hard to get them to show without some flickering, short black-out periods, or resizing of images as it transitions between the device load of the Marmalade app itself, and then Marmalade's step of loading your app code.
Marmalade imposes a very simple memory model, where you get a fixed heap up front, and all memory allocation is done through Marmalade. From the system's point of view the app just has and keeps a big block (or a few big blocks) of memory. This has some advantages, but I've had problems squaring this model with the iOS model of, for instance, receiving memory warnings and being expected to jettison any unnecessary resources. It appears to be a case where "one size fits all" ends up actually losing some key functionality.
You can use the extension manager and some other methods to show native UI elements, but integrating a significant amount of native-look-and-feel UI can be a challenge. So if your app is game-like and users can deal with non-standard buttons and so on, that's fine, but if you anticipate needing significant native UI, it is harder. [edit: Recent versions of Marmalade have added a native UI framework that lets you specify standard UI elements in a generic way and then implements then using the appropriate widgets for the device. I have not used this, but it looks fairly comprehensive.]
If you run into problems, it's often not clear whether it's a generic OS problem or a Marmalade problem, and it can be lonely trying to find help. For instance, I recently added in-app purchase to my game, on both iOS and Android. IAP is challenging, and even without an additional SDK layer there are lots of special cases to deal with. In my case, I had a situation where my app had been rejected by Apple for a small issue, and while it was in the rejected state my in-app purchase was also in a "rejected" state (even though there was nothing broken about the IAP itself; this is just a quirk of Apple's process). When I was trying to regression test the in-app purchase functionality (while I was submitting the fix for this non-in-app-purchase-related issue), the game was actually crashing, instead of getting an appropriate error result. I was able to determine that the crash wasn't in my game code, so it was either the OS (unlikely) or the Marmalade middle layer for handling the in-app purchase callbacks (which is what it turned out to be [update 11/28/2012: Marmalade has reportedly fixed this problem in a recent SDK update]).
So in a situation like that you can try going on Stack Overflow to get help, but really nobody is there to help you, so you are dependent on the Marmalade team to get back to you with an answer. As I say, they do a pretty good job of this, but there's no way it can compete with nearly instantaneous responses on Stack Overflow from the world-wide community of regular iOS programmers. So I'd say this last one is my biggest concern with using a system like Marmalade. It saves you time up front not having to come up to speed on the details of the various platform SDKs, but when you run into problems you are "at the mercy" of the Marmalade team (or friendly Marmalade community members) to get back to you with an answer. (Keep in mind here that I'm writing as a freebie indie developer who just gets standard priority for issue resolution. You can pay to get guaranteed quick resolution.) For me personally, it's been hard having to keep coming back to my producer and saying "I'm waiting for an answer from the Marmalade guys on this one."
(Another example of issue 3 is that until recently there was a problem with sound effects being delayed on certain Android devices. It was a Marmalade issue, and they did eventually resolve it, but it took a while, and there's basically nothing you can do in the meantime.)
Keep in mind that (as other responders have pointed out) even without Marmalade you can still have the bulk of your code base in C++ on either iOS or Android.
In spite of the long list of potential issues above, I am a fan of Marmalade, and I appreciate all the company has provided for me for free. The tool really shines when it comes to other platforms that you'd otherwise never bother with, such as (for me) bada or PlayBook. You really can deploy to a wide array of devices from the comfort of your PC and Developer Studio (or from a Mac with xcode, if you want to make your life a little harder ;). The simulator tool they have is great, and there have been only a small number of instances where I've had to debug on the device itself; in general if it works on the simulator it just works. IdeaWorks has taken on a huge challenge and they are doing a great job juggling all these features (i.e., basically every features ever offered on a mobile device) on all these platforms (i.e., all significant devices in existence, with the exception of Windows Phone 7 because it does not currently allow native code). It just comes with some caveats.
I am biased, being the CTO at Marmalade... but if your key requirements are (1) camera access and (2) the ability to "squeeze out every little bit of processing power available" then Marmalade is a great choice.
Marmalade compiles your C/C++ to native ARM (or x86) instructions... no transcoding, no virtual machines. It's very easy to bring across existing C/C++ code, nearly all the C/C++ standard libraries are supported, etc. And you can use ASM code within your project. Also, you can do all your development either on Windows or Mac, regardless of what platforms you deploy to (yes, you can even compile/test/deploy to iOS purely on Windws).
As far as I can tell you from ANDROID Development:
The Camera API from Android itself seems to be a little buggy (in example: before 2.1 there is no solution to get Camera shown in portrait-mode without scrambling the Images).
Another abstraction layer on top of that might be better (in terms of accessibility, features, whatever), or even more worse. What it does for shure: It steals resources, which may be needed for your own App.
Marmalade offers an excellent Native Extension framework
http://www.madewithmarmalade.com/marmalade/features/extensions-development-kit
WHich ultimately means that you can jump directly to a native implementation of any particular feature. You still keep the core benefits of cross platform development for your main app.
Also on android because marmalade makes use of the android NDK your c++ code for processing data will be running faster than the corresponding android Java code.
Im making games with Marmalade and the extensions and native code speed make me extremely confident of being able to deliver at least as well as a 'native' app.
I would use MoSync Android/iOS, but I would say that, since I work at MoSync.
But in all fairness I prefer the MoSync Camera API.
If you really want to squeeze out all the processing power out you should use ASM.
/Tony
Marmalade's not bad, I used it in 2013. Some bugs, some annoyances (fixed memory pools), but overall not a bad experience.
The only real disappointment is the lack of support for Linux. I cannot see how the Marmalade guys can support obscure platforms like Blackberry, but not Linux; it makes no sense. Maybe this will change as Steam OS (a Linux-based, gaming-centric platform) matures, though admittedly Steam OS doesn't bring a whole lot to the table outside of what other OSs bring, for now.
In the recent weeks I have been busy with the issue of cross-platform development. That starts with the problem that I had the feeding to write a wrapper for the communication-API of MoSync (I don´t knew this SDK and others for cpd before). It should be used in our Java environment for instance to easy create a bluetooth-connection to different phones and so on.
For me the other question is now, how I can use such SDKs like MoSync, Titanium and others in a existing project? In my opinion it is not possible. Either you develop nativ or with a cpd-framework.
I would also be interested in when do you recommend this frameworks (I know already that there are some other threads about this). I personally would say that there isn´t a great future for this SDKs because of technical drawbacks and dependencies. In addition, the market for cross-platform solutions (hybrid, interpreted, cross-compiler) is at least as fragmented as the market for mobile operating systems themselves
What are your experiences?
Martin
Cross-platform implementations of any type, on mobile or anywhere, are primarily to reduce the time to market. That statement may look like oversimplified, but it more or less holds true. So, the ideal situation to use it would be to have an application/game that maybe, uses the common denominator of features across the smartphones, which could include touch, a decent UI, the network, maybe the accelerometer in some cases LBS. So, you land on multiple phones in quicker time and reduced development cost.
If you are looking to utilize a lot of hardware specific features, then we land into what's commonly known as the unknown territories. Then you have to do what people always do, gather more information about the landscape of phones to target and see if the "chosen framework" has the power to dish out the features on those platforms. In this case, you cant possibly deploy one off-the-shelf.