Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm not sure if such question is suitable for Stack Overflow because it doesn't include code but since "Stack Overflow is a question and answer site for professional and enthusiast programmers" I bet that many programmers are wondering exactly this and some (like me) know nothing about Android devices but are forced to prepare a website for that platform.
So, the question would be: what Android device, in reasonable price range, is best for web development? It's a pity that their simulator is buggy and too slow on Windows machines. Up to date device seems to be a good time-saver.
I have one HTC Wildfire ( for bad small screens ) , had one HTC Desire (bravo) but I broke it :( , one HTC Desire HD for Good screen and single-core cpu and now I bought a used HTC One S which is a dual-core high res phone. I also have one 7 inch cheap Chinese tablet which is good only for testing.
In general , your apps should be working good in low-end devices, like htc wildfire, samsung galaxy mini/ace. If your performance is acceptable in these devices, then your app will be very good in top-end devices ( like HTC One .., Samsung galaxy s3 etc).
The problem comes when you want to see how the GUI looks like in different screens. So in my case I have one phone with very small screen , one with a good resolution and one with high resolution. Most modern devices are covered in these cases, the rest you can see how they will look when creating the layout xml in eclipse and viewing the result ( no need to open the emulator , except for dynamic data ). When viewing how the xml will look like, eclipse give you the ability to display it in many different screens ( or even custom sized ones ).
I wanted to post this as a comment to your question, but I don't have enough internet points for that.
I just want to address one part of your comment: "It's a pity that their simulator is buggy and too slow on Windows machines." I had the same sentiment (It'd take me around five seconds to step from one line of code to another), until I installed the x86 emulator. Suddenly, the operation was blazingly fast. This is largely because the x86 emulator is able to use the CPU's VM acceleration.
Take a look at the documentation if interested.
Related
I'm currently designing a digital menu application for Android tablets.
Here's how we are currently working: each restaurant receives a number of Android devices with our application installed (mostly 7 inches tablets) - they are low-end devices of various unknown and weird brands. They are all 4.0+, though.
We tried our best to optimize the interface based on a 7" 1024x600 testing device, using dp and sp units. Unfortunately, there are a lot of models that behave differently from this one despite the fact that they have exactly the same physical size and resolution! Actually, I did not find any device to behave the same as another... how is this possible?
Another great issue is instability. Even after exhausted testing on some models (some low-end, some high-end - such as Samsung's latest models) showing no exceptions or errors at all, we find some tablets randomly crashing with no apparent reason - same setup, same app, different tablets. Many times it is impossible to know what caused the crash, since it won't happen on a developing environment and there's no log; also, reproducing the steps that led into the crash won't result on any problem whatsoever.
My question is: are those problems sitting on the low-end tablets manufacturers' hands or is this somehow related to the way we are developing? Are those issues manageable at all?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
When i select my virtual device in eclipse and click start this is all I get.
Yet in all the tutorials I've tried that have screen shots to help aid the reader, their AVD looks like this
There are also some other inconsistencies with how in these tutorials (vogella and android developers) the screen shots have options and sections that I don't have even when I follow the directions to a T. AND OF COURSE THE SIMPLE HELLO WORLD PROGRAM IS NOT RUNNING WHEN I TRY IT IN THE AVD
Can't understand why it's different for me and not working.
I'm using windows xp home sp3 32 bit with 1.5 gigs of ram
wait for the first time,open console and see what it logs, if red error appears "failed to launch, timeout or other ... (it's in the worst scenario, it's here time to panic), or simply when You'll see your second(good) screenshot - loaded device - just run once again.
first booting could be up to 5 min (2gb ram),
when it finally appears, I hope, (loaded desktop with icons) dont close it, until you're really need RAM for other PC tasks.
btw there are some common advices how to speed up booting:
• snapshot
• custom ini file
• disable booting animation
• use real device
• use host GPU , in virtual device settings (for faster response, when avd is already loaded)
• smaller screen size ( for typical hello worlds 320x480 would be ok)
i takes time to load. Like booting up your phone. Once it's open don't close it. you can run and test your app on the same emulator. Remember, once you close, it takes time to load again. Upgrading your ram might help boost up the speed
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.
Developed a application of size 40MB. I need to test it for all screen support but the android emulator really a bad choice(I feel... ). It gives Insufficient memory error almost every time). How developer test their application?
One more Question
I have designed app for four different layout(normal,small,large and xlarge). Will every device(In future) satisfy these layout params?
And i faced a real problem that i tested my app in Sony xperia minpro(Small screen 240*320 2.4inch) and in Samsung galaxy 5(smallscreen 240*320, 2.8inch) but the layout is overlapping in samsung device. This can be a serious problem , actually we cant check our app in every device.. that is impossible too.
TIA
40MB is way too big for an Android application. Many users will have problems installing the app on their devices. You should consider moving some resources out of the application and downloading them either on demand or on first app run.
The list of layout types (normal, small, large, xlarge) is definitely not final, for there quite possibly will be even larger screens (xxlarge) or tiny ones (xsmall?).
Developed a application of size 40MB. I need to test it for all screen
support but the android emulator really a bad choice(I feel... ). It
gives Insufficient memory error almost every time). How developer test
their application?
You can configure the emulator with any amount of memory you wish, including an emulated SD card so memory shouldn't be a problem. However, 40MB is quite big so you may be hitting the package size limit.
One more Question I have designed app for four different
layout(normal,small,large and xlarge). Will every device(In future)
satisfy these layout params?
You're asking us to predict the future - there's no way we can know what Google are planning if they haven't already announced it though I would suggest that there will never be a commitment to keep screen sizes or resolutions static - technology constantly evolves and specs that are OK for today, will not be OK for tomorrow.
I have seen dictionaries weighing in at 40Mb, best practise is to download the database as a separate file. Some graphically intensive games approach that size. If you want to emulate many Android devices make sure your PC is up to snuff and you have the latest SDK.
How developer test their application?
You do not have so many choices: you have to use as many (and different) physical devices as you can, from different vendors and technical specifications (screen, etc), to try to detect as many specific bugs as possible.
This is difficult, as you are often limiten to a few physical devices.
To give you examples, I recently struggled with the Camera, for a bug happening with Motorola Defy only. I am currently struggling with the Camera, but only for Samsung Galaxy this time.
When you find a specific bug, try to fix it "the general way": instead of detecting the vendor/version of the device to write specific code for it, try to enhance your code in a way it will work for all tested phones. So far, I never had to write anything specific to a given device. The bugs I encountered were always tied to a permissivities or particular cases that could be handled by making the common code more complete or resiliant. Let's say by "making as less assumptions as possible" knowing that we tend to make assumptions without meaning it.
On top of testing on as many physical devices as possible, create emulators. You can parameter them to have different screen layouts, different embedded hardware, memory, etc. And on top of the default emulator that comes with the Android distribution, you also have emulators provided by the devices vendors and that reproduce the specificity of these devices. For example, Samsung released a Galaxy Tab emulator. Sony Ericsson released a EDK Cellphone emulator. You can get them thru the regular android distribution update workflow.
Will every device(In future) satisfy these layout params (normal,small,large and xlarge)?
Yes, as Android distributions are backward compatible. Any of these layout will still be supported in the future, but may become 'deprecated' (so not recommended, but still working), and new layout types will certainly be created.
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 11 years ago.
before publishing a new app on the market, on which devices would you suggest to check whether it runs fine or not? What are your experiences? How do you handle this?
Are there some empirical values, for example, do applications that run smoothly on a HTC Desire behave similar on all HTC devices? Are there some devices on which the app should definately be checked?
I like to picture myself releasing a high quality product instead of throwing some crap on the market. :) But I suppose I am not the only one who cannot buy like 5 or more devices just to ensure that the apps works fine on every kind of device.
Well, at least not yet... ;)
Thanks for your help!
Best regards
S.
The most problems in my app are freezes on droid... no other device reports freezes... just droid.
If you have access to different devices, very good. If not, test at least all possible screen sizes and densities with the emulator. Thats my advice.
I recommend testing on touchscreen and 5-way navigation in addition to varied densities. Testing screen orientations might be good, too, but I haven't figured out how to do that with an AVD.
I would recommend getting phones that represent various tiers of hardware. Check for performance on low end devices like the droid (can't believe I'm already saying that after less than a year) to make sure that your app is not too demanding and will run smoothly. Also check on a high end device like the EVO to make sure it looks presentable on a fancy device with high def screens.
Another nice device for testing is Nexus One. It's middle of the road, has nice screen, decent hardware, and runs Froyo, without being the latest and greatest.
I test with a droid, and although my app runs flawless I still get comments and 1 star ratings for crashes on other phones like X10, EVO, etc.
I too focus on quality and dont want to put a half tested app on the marketplace. I spent TONS of time on testing. In the end, it didnt work on some phones and there's really nothing I can do about it.