I'm using MSVS2015Pro with C#/Xamarin.
I have a laptop that doesn't support Hardware Acceleration.
Then I have a question: can I develop for mobiles without having to spend too much time when deploying?.
I could deploy to my real android phone, but I don't know if that's slower than deploying to an AVD. Is it?
What Can I do? I don't wanna do things in a very slow manner.
Do I have to buy a another laptop that supports Hardware Acceleration?
If that's the case, what other requirements I need for that other laptop?
We are running windows 10 with VS 2015 Pro and no hardware acceleration available on the CPU. There is indeed a solid state drive and 16gig ram (The ram doesn’t really assist in running the emulator though. More ram doesn't make the emulator faster. It is rather the processor and or GPU. The ram does assist with running multiple emulator instances.)
Doing both xamarin.iOS and xamarin.android development. I would agree that with hardware acceleration things would be much faster but it is possible to dev on an enterprise level without it. The deployment to emulator (once emulator has started up and is running) vs actual device is much the same. It is indeed faster running the app on an actual device.
I would suggest using actual device to test functionality and the user experience of the app for quick feedback cycles while using the emulator to test different OS versions for compatibility.
Related
As many other videos, this official video from Microsoft and James Montemagno casually demonstrates an Android emulator that runs on Windows without any noticeable lag. It's just fast.
To keep the experiment undistorted, today I tried to run a "Hello World" Xamarin.Forms app on a top-spec Surface Book (i7, 16GB RAM, NVidia GPU, 1TB SSD) with the latest Windows 10 and Visual Studio 2019 Enterprise.
The emulator runs very, very slow. It takes forever to start. It takes forever to wait until the app gets installed on it and meanwhile Android complains about unresponsive System UI process and suggests to kill it. Once it finally gets deployed, it takes forever to click through the Android UI to actually launch the app.
The question is: how can I configure an Android emulator to run as fast and responsive as official Microsoft and Xamarin videos demonstrate? ("nice and superfast")
As recommended here, I have tried both to run it with HyperV and with Intel HAXM.
I have also tried to force the emulator to use the 'host' GPU and use more virtual RAM.
I know that you can set up the emulator to save state, but this only makes it to start faster while it still remains very unresponsive.
Update 1:
Microsoft officially recommends to use Google's emulator and I am not sure it's the one promoted by James Montemagno in a recent blog post (thanks #TonyMkenu).
I was dealing with similar issues on my PC and I found that the emulator ran much faster if I started it up and waited a minute after the emulator appeared before trying to run my app.
I am using a remote desktop having configured Win 8.1, 3gb ram DDR2, 15gb HDD free space, latest Xamarin Studio Starter version with api 21 packages. When I try to debug a simple "Hello World" solution on studio, the manually created AVD loads too slow, even android home screen does not appear after 1 hour. What should I do to speed up the process ?
I don't know if your IDE supports it but you should really try out Genymotion, it changed my development time and testing significantly.
https://www.genymotion.com/
Considering your configuration, 1 hour is too much, try restarting first.
If not go for your Android device(physical), I debug on my mobile(you don't have to wait for your mobile to start).
You Can also go for Genymotion . Many find difficulty in genymotion setup. it is pretty simple though, follow this video If you'll understand once about VirtualBox and IP, it'll be easy for next time
I would recommend 6GB Ram and i5 processor for performance lag problem. So if it is possible, you should upgrade your machine.
Thanks for your responses. Finally I have resolved the issue by creating a low resolution Android Virtual Device (Nexus One) by Xamarin Studio.
But another problem arises, the published apk file is too large.Which steps need to be done to make it perfect ?
You should try the Xamarin Android Player. In my experience it's the fastest option over Genymotion and Android's AVD images even with Intel's HAXM installed.
https://www.xamarin.com/android-player
Nowadays a good deal of laptops come with 2 GPUs - a high-performance one and a power-saving one (less powerful). Most of the application, which I use on my laptop run with my integrated(power-saving) GPU, but still some of them are set to open with the high-performance card. I am trying to config the app which I am building to run on the high performance GPU by default, but I can't find any information about the topic anywhere. I hope that someone can shed a bit of light onto this. I will distribute my application with an NSIS installer and I guess that I'll have to add the path of my application to a list of applications for NVidia/ATI cards. The application is programmed in C#. Also, does anyone know how things stand with desktop PCs? What happens if a PC has 2 GPUs and I have to choose the more powerful one?
Milcho
We have a near complete application, and are trying to squeeze under the 50MB download limit for Google Play.
When inspecting our APK to try to find ways to drop our file size, I noticed the lib\x86, lib\armeabi, and lib\armeabi-v7a directories that are described here. They correspond to the 'Supported architecture' option in project options of a Mono for Android project.
If I remove x86, I save around 1.1 MB on our APK size. (This is almost enough to get us under 50MB)
What are the drawbacks for removing x86?
Will my APK still run on x86 devices?
Is there any substantial market share on Google Play for x86 devices?
If it will not work on x86, will Google Play prevent my APK from being installed on x86 devices?
Note that the following answers are for general Android development and do not reflect anything specific to Mono:
What are the drawbacks for removing x86?
Your app will not run on x86 devices. Intel may cry.
Will my APK still run on x86 devices?
No.
Is there any substantial market share on Google Play for x86 devices?
IMHO, not presently. A few handsets were released in 2012 that are Intel-powered (e.g., Motorola RAZR i), and the first generation of Google TV devices were powered by Intel CPUs. But Google TV has switched to ARM, and it will be some time before Intel CPUs make up a substantial portion of the Android device ecosystem (again IMHO).
If it will not work on x86, will Google Play prevent my APK from being installed on x86 devices?
It should. If not, the Play Store has serious issues. While I have a RAZR i sitting here, I don't off the top of my head know an app that uses native code that does not ship with x86, to see if the app in question is indeed filtered out of the Play Store.
are trying to squeeze under the 50MB download limit for Google Play
If a 1.1MB savings "is almost enough to get [you] under 50MB", you are already in trouble. Apps tend to grow, not shrink, over time. If you expect that you will be able to switch to some other distribution architecture (e.g., use APK expansion files) eventually and just need a short-term stop-gap solution, cutting x86 may be OK. But you really need to have a plan for dealing with app size growth that takes you back over the 50MB barrier, and you may be better served addressing that now rather than shipping something and finding yourself painted into a corner as a result.
I just made a Windows phone app and tested it on HTC Windows phone. Since there're multiple manufacturers out there, such as Nokia, Samsung, do I need to test on all of them to make sure the app work fine? Thanks!
As far as testing goes it's most important that it works on a Windows 7 phone as well as the emulator. Device specific concerns are not as real as they were with previous Windows Phone operating systems. The WP7 devices are all standardized - even the resolution of the screen.
In theory - you may not, but in real life there are some shades. First of all it would be useful to test application in different screens' sizes (3.5"-4.7") some elements can be extremely small for touch in 3.5". Phones of the first wave have old processors so when i.e. Lumia 800 draws UI quickly, the, let's say, Omnia 7 can do it slower with lags.
Also is very strange thing I figured out for myself - many bugs are reproduces only on the HTC Mozart o_O. Also don't forget to test your application in the emulator with 256mb of ram.