I'm looking forward to implement a process to develop and integrate user interfaces for mobile developments in for a mobile development team. Currently we are facing problems such as communicating user interface requirements such as screen sizes, etc... by the developers to the UI designers and when developers receive the designs from the UI designers there are alignments issues, low image qualities, font sizes are different and so on. How do the designers test whether their designs are appropriate for the respective screen sizes.
First, I would strongly recommend reading Designing for Multiple Screens documentation carefully as it describes very important aspects when designing your app for multiple screens
Second, Android Development Tools recently added very useful feature to preview your app on multiple screens at the same time. See the attached image, where I am highlighting the button where you can select Preview All Screens
Related
I've been using Xcode for a few months now to create basic iOS applications. Within the startup settings, it allows you to select 'iPhone', 'iPad' or 'Universal'.
I usually setup my applications so that they are locked portrait on iPhone and locked landscape on iPad.
Firstly, how can I setup my project so that it is available to both smartphones and tablets when pushed to the Google Play Store?
Secondly, is there a way to set the orientation to portrait for smartphones and landscape for tablets?
I think what you want is that the app should adopt its view according to whether the device is a phone or tablet. If so, Android provides a very good design called Master-Detail Flow. In a master/detail navigation flow, a master screen contains a list of items in a collection, and a detail screen shows detailed information about a specific item within that collection. And the beauty of it is that, in a phone it only shows the master view as a list and in a tablet it shows both master and detail in two panes.
Take a look at this and this
Also for other adaptive UI see this
The concept of Android O.S is entirely different from iOS. Primarily, think of all the Android devices that exists! Lot of manufacturers, in different screen sizes and with varied configurations. However, an Apple iPhone is designed and manufactured by Apple, and it comes like a brick in different sizes. So it offers more of a robustness to the developer.
But in Android, due to it's versatility, there comes a need to design apps that runs equally same in all devices even with different screen resolutions. As a result, Android uses a technique called DIP Display independent pixels to address while designing. [This] is the perfect place to get a structured knowledge on Android UI designing and scaling to different screen sizes.
Now coming to your second question, Android offers superior flexibility to the developers. And you can easily adjust the orientation programmatically:
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE); //<-- Landscape mode
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT); //<-- Portrait mode
Hope this clearly answers your query!
I am familiar with android 2.2 and I have been developing for phones, now where to start from when developing for ICS tablets. The major thing I learned from quick-google that now I will have to use fragments for multi-pane layouts rather than mere Activity. What else do I need to look for before starting?
Some links would be helpful (for fragments too).
Here is how you can set up your Emulator to act as a tablet.
Here is a great guide on supporting tablets and handsets.
And lastly a very useful guide for fragments
You should learn about making UI's look good for different screen sizes, look into size specific drawables and resources, also making use of the screen. Look under training in developing on d.android.com
I have been developing Mobile phone apps in Mosync(Cross Platform C++ API - can make apps in iOS, Android, Symbian & Blackberry) & I am looking to develop apps in something else because of the limitations of Mosync.
But I dont want to move to a different API to find they have the same or worse limitations. I am thinking of moving to native API's (iOS or Android) but am open to other cross platform API's aswell.
If I was to move to Android OR iOS OR insert API here would I experience these limitations:
Resizing images is expensive(in terms of RAM & speed). IE, so can Android, iOS handle resizing 10+ images(for eg .png) & display them on screen in a relatively fast amt of time? In Mosync doing such stuff depends on the phone RAM but on HTC Desire(512mb) it takes about 6 seconds which is unacceptable for my app.
Does the API come with its own fonts & layout managers? Mosync doesn't have its own fonts, you have to create & import it & you cant change the colour of a font. You also cannot make the text in a widget display centred or word wrapped, can Android/iOS/other do this?
Can you create your own skins(.png) for buttons(any widget) & set a default API button's skin? This is actually a strength of Mosync where you can change button skins BUT it divides the skin up into 9 sections & only the 5th section is scalable, the others stay the same size, so on small phones a lrg skin looks weird.
Is it a REAL headache designing your app layout because of all the different potential phone sizes there are, so the widgets placement & skins will be incorrect on small screens & images will be out of proportion on large screens? Does the Android/iOS/other API help you by automatically laying out your GUI no matter the phone size & does it automatically scale image widgets & fonts to suit phone sizes?
Any info would be really helpful to a Junior programmer(intern) who is developing mobile apps all on his own & finding the myriad of phone sizes so ANNOYING to compensate for
My experience with Android Code:
Image resizing - Many current android apps seem to meet your
performance requirements although you don't mention the size of the
images which is the key issue.
Android supports many fonts internally, allows full control of font size, type face, colour etc
Android supports a complex variety of 'Drawables' including standard simple
graphics, 9-patch pngs (similar to what you describe) and simple vector descriptions of shapes and colours.
Android was designed with the difficulties of multiple screen sizes in mind; It supports multiple layouts for different screens sizes and orientations. This problem is intrinsically difficult and imho Android takes a lot of the trouble out the process - but it is always going to be a little bit of headache.
I am just reaching production on my first serious android app and have found the development experience pleasant and the learning curve easy.
We're working on a port of an iPhone game to Android. One of the additional hurdles with this is all the different device resolutions Android has. We're having our art team rework the art for each target resolution (we're only picking a few for now with more later.)
My question is, can we (and how best to do it) submit separate packages for each resolution to the Google Market under a single title so that when someone purchases it they get a specific resolution?
UPDATE 7/21/2011
Although we released without it, it was just announced that the Google Android Market now officially supports multiple APKs for a single app.
http://android-developers.blogspot.com/2011/07/multiple-apk-support-in-android-market.html
You don't have to do extensive job to support every possible screen size, you only need to make resources for several configurations and Android will do the rest. The major concept here is that there are several screen densities you have to support. Once you've made a resource for each density, Android will automatically use an appropriate resource for the specific device. You only upload a single application for all the devices.
You should read an article on supporting multiple screens and also on providing resources.
I have not seen such an option while uploading my own applications to the market. This is a good/official explanation of how to program to various screen resolutions.
If it is impossible for your to package all of your resolution-specific resources into the app, you can download the images from your servers after the initial start-up of the app. At that point, you'll be able to grab the screen resolution details and only download what you need.
Recently myself and a small group of friends became interested in developing a game for a mobile platform. Originally we considered the iPhone but none of us use macs, so we decided Android would be a more realistic platform to use. Before we get started, I was hoping that I might find some answers to a couple questions so we don't waste our time if this project isn't feasible. Any help is appreciated!
I can't seem to find out how many programming languages Android supports. Java is obvious, but what about C+? It seems that Android supports C and C++ through Eclipse, but is that it? (I'm not the programmer for the project which is why I'm asking this. He's comfortable in C+).
Our game involves the use of two digital analog sticks (it's not a twin-stick shooter but it's a similar concept). It would seem that most Droid devices unfortunately don't use multi-touch though... Are there many devices out there right now which support this functionality and I'm just not seeing them, or should we possibly consider the development of a different game that would only use a single input?
Assuming there's no snags following those first two questions, what would you consider the best screen resolution to develop in? It seems like there are a variety of resolutions out there right now and we can't decide which is the best to use.
Again, any answers are appreciated!
You will have to use at least some Java, though you can call C++ with the newly released NDK.
To my knowledge at least the Droid and Nexus One support multitouch. Not sure about the newer ones.
I would develop for multiple screen sizes.
Chris Pruett did two very good presentations on writing real time games for android you may want to look into, they were a huge help for me.He also lightly touches on the NDK in the second one, linked below. I can only post one link since I'm a new member, but a google search for "writing real-time games for android" should turn it up.
http://bit.ly/checYY
1) Java is the language of the SDK. The majority of apps are and should be written in Java. The only reason for the NDK is for apps previously written in C++ that are to be ported to Android. There are downsides - it only supports compiling to 2 different CPUs (one is the Nexus one's CPU, can't remember what the other is). So if you do use C/C++ in the NDK, you are seriously limiting the number of devices you can ship to.
2) If you want to use dual analog sticks, why not display the sticks in the corners of the screen and allow the user to place their thumbs on them? You don't need hardware support.
3) Android SDK supports multiple screen resolutions so you don't necessarily need to worry about it immediately. I would aim for WVGA to start with (800x480 - Nexus One / HTC Desire).
Your first question has been answered by others already. The SDK is based on Dalvik, you're going to have to speak Java to the Android framework to do things like set up your activity, handle events, etc. You can call into a native code module built with the NDK for other things.
The multitouch situation on Android is dependent on hardware. Android >= 2.0 supports it in the framework, and you can use the PackageManager to query for what kind of multitouch functionality the device supports. The two you care about are FEATURE_TOUCHSCREEN_MULTITOUCH and FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT. Some screens that only offer FEATURE_TOUCHSCREEN_MULTITOUCH have problems distinguishing precise movement when both fingers are along or near the same X or Y coordinate. This is fine for things like zoom gestures, but you might have problems doing dual-analog style controls on a device without FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT.
Plan on supporting multiple resolutions. If you provide low and high resolution assets the resource system can select the appropriate ones for you automatically at runtime. More details on this here. You will still need to deal with different resolutions that do not necessarily share an aspect ratio. For example, the Droid is 480x854 while the Nexus One is 480x800.