As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a task to convert an iPad application into Android tablet.
I get into my concerns right away.
iPad screen resolution and size is only 2 different versions, so you design in the small resolution and add graphics for the bigger one too. That's fine in Android you have the drawable folders. But when you testing in emulator shouldn't I set the resolution iPad like? 1024x748 and test my app there? OK I will have my values with dp,sp, wrap content, fill parent, but my target devices are tablets. What would your opinion be in setting up the emulator for such kind of task?
Next is what about some things with architecture. In the iPad I have views and subviews, child controllers appearing "on top" of the other controller. This can happen with fragments I think so far but, can these fragment layouts have a dimension? or you are just hanging on wrap content etc? I mean you have a view 1024x748 and another view appearing top of it bottom right on the screen 300x300 for example. Different controllers, different views, exchanging data! Any example tutorials on such a design?
Can I just show a "popup" kind with various views inside in a specific position on screen? Like you push a button and a view rectangle with a pointing arrow appears next to it.
Thank you in advance and I hope you can understand what I'm asking. Comment for any inconsistency.
What's your question here? You have to create a similar App on Android as you have now on iOS. The two platforms are different, both in API and in UI terms. Thus, first of all, you/or a designer at your cmpny have to redesign the app, so it fits into the Android world... So in other words, what matters here is "WHAT YOU DO", not "HOW YOU DO"... You have to design the same experience for your Android users... And that does not start with simply porting your app, and coding.
You should NOT simply take features form the iPad app, and directly force them into the Android version, as the look&feel, the behavior of the two systems is different. You should dig deep into Android Design Guides before starting that... HERE and HERE
E.g.: In the iPhone world you can use absolute positioning, as you have only a few valid resolutions. In the case of Android, layout has to be dynamic, as you have tons of different resolutions. The recommended layout of programs, the number of hw buttons, these are different. The user expectations are different. An Android phone is operated differently from an iOS based device... Users are expecting functions to be accessible in different ways...
Another approach is to use a framework that enables designing apps for every different platform. Thus, they have an abstraction layer on top of which (with it constraints) you design your app, and than you are able to release it to all of the different platforms (iOS, Android, WP7, W8, Bada, etc, what the actual platform supports..). HERE is an article on such platforms.
I'll give it a try to make something meaningful out of this.
To the emulator screen size
Android come in any size and shape so you should develop for that. Sometimes it can be an advantage to actually set the dimensions in the emulator to something obscure just to see if it looks good. That said I'd test on the most popular tablet brands like:
Nexus 7, Asus transformer eee pad (1280×800)
Nexus 10 (2560×1600) (hard to test due to the large size)
Amazon Kindle Fire HD (1280 × 800) (same as nexus but some report indicate it is handled differently, so if you got a physical one test it)
In general you should always test on a multitude of screen sizes but also a multitude of devices as there always is some differences you don't think about (like with the amazon kindle fire HD), so get your hands on as many tablets as you can or use some kind of test service.
About architecture
Android has views and sub views as well. Fragments is a simple combination of code and view and like views have a size. Fragments can easily exchange data but it happens through its parent activity.
You don't EVER want to position different views at a specific position on the screen. Setting UI for android is more like setting UI for a webpage than for a newspaper. You don't have a specific size but a size that various for each device. So you should make a layout that can be stretched to the various sizes and still look good. This can be accomplished in numerous ways.
Related
The screens in my app needs to be displayed in the same way on both type of devices, phones and tablets. Currently my app works fine on phones, but they behave weird when run on tablets. The problem occurs with the positioning and size of components in the screen.I have 9 patch images generated for all the images being used but still for some components that I use absolute size/margin values such as 30dp,50dp etc do not seem to be good measures that work well on a tablet. Some of my thoughts/questions are:
PercentRelativeLayout - is it the best solution to overcome this
problem?
Is there a way that layouts can be defined so as to draw
differently on phones and tablets. Please note that that I do not
have any complex menus or behaviour that needs to work differently
on different devices, they are same.
Do I have to develop 2 different apps?
you have to make different layouts for both android phone and tablet.
Look at this link
Read more on the Android developer documentation after reading answers above. Found this resource to be more explicit for someone who is totally unaware of supporting multiple screens. http://www.survivingwithandroid.com/2012/07/how-to-support-multiple-screen-in.html
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 9 years ago.
Improve this question
Is there a difference between developing for a smartphone vs for a tablet? i.e. iPhone vs iPad, Android vs Android Tablet. What are the main differences to take into account? I know its a broad question, but trying to wrap my head around the difference.
Edit:
If a company can develop for iPhone apps, does that mean that the company could easily develop for iPad as well? Do companies specialize in iOS smartphones and not iOS tablets?
The main difference is screen size. Sounds like an open door, but if you actually write apps targetted at both phones and tablets, the differences become very clear.
Take sending an email from your app. On iPhone you get a nice full-screen mailer. On iPad, full screen would be too much of it, so you need to embed it in a smaller overlay.
Take scanning a QR code. On iPhone your screen is just the right size for such a thing. An iPad is just a little too big.
Take having a "More..." menu. On iPhone, having 4 rows saying "About", "Settings", etc is a good design. Having the same 4 rows full screen on iPad looks really, really bad.
For iPhone/iPad in the examples above, you can read Android Phone vs Android Tablet of course.
On the low level OS side, there is no real difference. It's the same OS.
One of the best answers is from what you'll find on developer.android.com
Each screen size offers different possibilities and challenges for
user interaction, so in order to truly satisfy and impress your users,
your application must go beyond merely supporting multiple screens: it
must optimize the user experience for each screen configuration.
Usually the programming is the same the only change is layout and maybe a few extra buttons or less buttons.
UI design is the main difference. Tablets have more screen space. In most form/control-based apps (as opposed to games), this makes you redraw pretty much the whole app layout for tablets.
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 4 years ago.
Improve this question
I want to develop an application for Galaxy Tab and Android phones. The tab and phone UI are very different. Like in tab, we have used fragments, etc. and on the phone we want to use tabs.
I am aware that by using layout-small or layout-large I can show different UIs, but what about functionality?
How should I proceed? Is there a simple way to handle functionality also for different screens? Or is it better to create two applications finally?
First be sure to read this recent blog post that gives an overview of how applications see different screen sizes and can adjust to them:
http://android-developers.blogspot.com/2011/07/new-tools-for-managing-screen-sizes.html
This post has some examples of basic adjustments -- providing different layout files for different screen sizes.
This is also something that the fragment APIs are intended to help with. If you are already writing your UI with fragments, you are most of the way there -- showing these in tabs does not require a totally different implementation, just use the fragments to populate the different tabs.
If you are targeting Android 3.0 or later, this is easy because the action bar already has simple mechanisms to have its tabs allow switching between fragments. This API demo provides a very simple example of its use:
http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/ActionBarTabs.html
If you want to run on older versions of the platform, that is what the fragment APIs in the v4 support library are for. These allow you to write your app using fragments and still be able to run all the way down to Android 1.6 (API 4) of the platform. In MR2 we also added some sample code showing how you can use the support lib fragments with the old tab API.
Sample code for this is included in the now deprecated TabActivity class:
http://developer.android.com/reference/android/app/TabActivity.html
There's no single answer to this - it's a broad topic.
One thing to keep in mind before you start, is that there's currently a lot of code floating around the web that assumes you can judge a screen size by the platform version: IE, everything up to Gingerbread is a phone, and Honeycomb (and up) is a tablet. This is a bad idea. Don't do this :) Also try to avoid a massive switch case that just executes different blocks of code based on width/height values you pull from the system. I'm not going to describe how to do that, others have already given that answer.
One thing to investigate is the Android Compatibility Package - It lets you use Fragments and Loaders (which were introduced in Honeycomb) in earlier versions of the Android platform. One common pattern this enables is to let you set up a nav fragment & content fragment which sit side-by-side on a Tablet (where there's room) but have the nav fragment switch over to the content fragment when an item is selected on a phone or smaller screen.
If you're just trying to have images that grow and shrink with screen size (that you're not drawing programmatically), the answer is 9-patches.
You also have the option, if it's appropriate for your application, of using Android Market's Multiple APK support. The linked page dives into how to set that up, and gives you a pretty solid description of when to use it and when you're better off with a single APK.
You can retrieve the screen size using:
Display display = getWindowManager().getDefaultDisplay();
int width = display.getWidth();
int height = display.getHeight();
You will have to have decided which screen sizes are required for the different features, such as setting the minimum tablet height and width to min_tab_height and min_tab_width, accordingly. Then do a check for if this screen size qualifies:
boolean is_tablet = false;
if (width >= min_tab_width && height >= min_tab_height) {
is_tablet = true;
}
Now you can check if (is_tablet) before allowing tablet functionality to your app (or if (!is_tablet) for non-tablet functionality.
Try splitting your app in seperate parts, one trunk containing core features that you develop as a Library, then two separate apps using the same core functionality with specific UI design, one for Tablet version of Android (>3.0 HoneyComb) and one for "phone" versions (<3.0).
My experience with GalaxyTab-likes (basically a tablet with a 'phone' non-HoneyComb version of the OS) is that phone layouts do stretch nicely to fit the 7 inch screen. So it might be enough to add a specialized layout.xml specifically made for big screen. However I didn't even found it necessary on my own app...
EDIT:
also not that if a tablet is running a non-honeycomb OS, 2.2 or 2.3, like is the case with GalaxyTab and many 7 inch tablets, the functionality is exactly the same as on phones, so no specific redesign is needed if not for the layout of UI components.
EDIT:
read this page for specific and detailed information on how to support different screen size in your app. You can specify in your manifest the size of the supported screen for your app with
<manifest ... >
<supports-screens android:requiresSmallestWidthDp="600" />
...
</manifest>
So given the market now supports uploading several apk for the same app, you could compile different version of the app seperately for each screen size, and the market would filter them out according to the sizes in Manifest, so you should even never have to actually check for screen size in your code.
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.
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.