I am a newbie to the libGDX game development framework.
Can anybody explain the purpose of the "desktop" application? Is it necessary to create a "desktop" application for my android application? Is it because the class which launches my main application is in my desktop application?
Sorry for asking such lame questions. Kindly help me out and clear my basic understanding regarding such things.
Thanks in advance!
The purpose of the library the way it's designed is to allow you to create all of your game logic in a way that doesn't depend on the platform. That way your game can run on Windows/Linux/MacOS/Android.
As a result you can run your game while you're testing right on your desktop, saving you from having to package an APK and deploy it to an Android emulator or device. Your development goes much quicker that way (plus you get free support for platforms other than Android).
When developing with LibGdx you have one main project, which holds all you platform independent code (like 99% of code) and you have projects for other platforms, which are typically just one class. So, beside that main project you must have at least one more, platform dependent. And if you are using assets you must have android since assets (graphics, sounds, fonts) must be placed there. Having desktop project is nice to have, as Odat said, for testing - you can run your desktop app much faster and i.e. make screenshots, maybe record it as video....
For android or iOS development use your Desktop project for rapid development of your game mechanics. Load time is a fraction of the Android build and launch and much quicker than the emulator. Debugging is much quicker to setup and run in the Desktop project.
You can quickly add bits to your game and get immediate feedback on how it works.
Of course many people release fully functioning games with only a Desktop version. Tools even exists to package them with installers!
Related
Since I'm familiar with AS3, I'm planning to build a desktop app using Air, and I'd like to not run into limitations, I never developed a full blown app for desktop using Air, only small apps and others for mobile.
The idea of this app is to be similar to an IDE, with some visual management, think of the design view of Flex, something like that. But not that big, a smaller/reduced version of that.
I'm asking this because I don't remember seeing any app like that built in Air, and I wonder if there is a good reason, or not.
If for example someone says: "use Java, its better", please tell me why, and more importantly, what things I can do in Java for desktop that Air just wont allow me to.
IMHO AIR is extremely powerful and if you combine Stage3D + Native Extensions you can do almost everything with a good performance. I have been working in several projects for desktop, iOS and Android and using Starling + Feathers + Robotlegs + creating my own native extensions (plus there is a lot of free/open source/commercial) was possible to achieve all my (and clients) goals.
Also, there is a huge (ActionScript/AIR) community sharing knowledge and helping each other, several open source frameworks (for games, 2D, 3D, animations, GUI).
I have tried Objective-C, Swift and Java and of course, there is a lot of positive points, native performance, powerful IDE's, GUI integration, native components, etc.
It's a mix, if you need to have your app running in multi platform, I believe Adobe AIR is a good option, if not and you have the necessary knowledge to work using Objective-C/Java, use native.
Of course, it's all relative, I'm just trying to share some tips.
Is there any way which can be adopted, to create cross platform responsive mobile apps using Flash Builder ?
We are using our custom written Resigning Engine for this purpose right now, but we tend to replace it with any generic Resigning tool or to cater responsiveness for all kind of devices/platforms.
Being on the same cross platform development, i.e. Flex, Action Script and MXML, is there any solution for this?
Thanks
It's possible deploy Flex-apps on Mobile devices, see Mobile app development
at Adobe Devnet more details
You definitely can develop Android and iOS apps using Adobe Air, Flex, AS3, MXML and publish them on Apple App Store and Google Play Store. But it's limited to these platforms, and Adobe is very unlikely to add any new platform to this list.
Pros:
it's really cross-platform. Once your application works on one, it's really easy to get it working on the other; so the development cost compared to native applications is much lower;
you may have some OS specific features/design; using by example OS specific CSS directives;
You perfectly may create an app with a responsive design, all tools are provided, but like for HTML/CSS, it requires a lot of work;
you may access all phone features (sensors, camera, etc...) using Adobe Native Extensions
Cons:
the size of the generated application: as it includes the AIR runtime, even a very simple app will weight around 12 Mb (9 for the runtime + 2.5 for Flex);
the performances are correct but not as good as those of native apps; one of the reasons is that Flex does not allow to use GPU for rendering (but Flex is not a framework for creating games);
it would be costly to get an app looking like a native one, as you would have to mimic all of native components. There was a project to do this (Eskimo), but it looks dead, and the components were not polished enough to be used in production when they stopped the development;
Adobe Native Extensions offer is rather limited, and they are quite tricky to write; (these drawbacks are not strong ones: you can write extensions, assuming you know to write native code; and most of the common features are available as ANE);
like with any other cross-platform technology, there are a few issues that you can't fix by yourself; you just can wait for Adobe to fix them when it's a problem in the compiler or the AIR runtime; hopefully they follow a 3 months release cycle since they launched AIR on mobile;
it runs on Android 2.3+ devices only; and only devices that are matching the minimal requirements defined for the AIR runtime; that is to say, most of the smartphones and tablets, except cheap ones like ZTE products. When a device is not considered as powerful enough by adobe, the AIR based apps are not displayed in the stores.
Some recommendations:
The best way to organize your code is to create a project for each OS, with specifics assets (icons by example) and a specific manifest file (app.xml), and put all of your application code in a library used by these two projects. It will allow you to test your code (Flex mobile project can't be unit tested), and will avoid you permanent modifications of the manifest.
Worflow: it's usually faster to develop for Android, and then adapt you app for iOS, because it's faster to deploy and test on Android device (although you may use the Adobe Simulator most of the time).
Use the latest release of Apache Flex; it handles the high resolution devices. Forget Adobe's release (4.7 and lower)
Test quickly and often on mobile, especially for the responsive aspects.
Use FXG instead of bitmap graphics each time it's possible (i.e. if they arent animated); it's lighter and very easy to scale.
Mad Components
Alternatively, you may consider using Mad Components instead of Flex.
Flex was not designed for mobile at first; MC was. So it's faster (looks like native), and much lighter (although you still need the embedded AIR runtime which weights 9 Mb).
I have a webapp developed (game), based on HTML5 + CreateJS, but since Android lacks of standards, I've run into unsolvable issues for my webapp. That's why im recurring to PhoneGap.
Yet my confusion lies in the fact that I need to make this game into a phonegap app that runs on Android/iOS, using for each platform native specific stuff.
So, should I build 2 apps (one for each platform), all over again, or use the one I have and try to deploy it into different devices using phonegap?
The truth is I don't know how to approach this problem... can anyone help?
Best Regards.
Yes, you can use Cordova (PhoneGap) to create a cross platform mobile app. Basically, Cordova (PhoneGap is Adobe's version of Cordova) is an open source project that provides JavaScript API's for accessing native device functionality (like the Accelerometer or Camera.) Cordova also lets you package your app in the native application shell, so you put your app on the app store. Please see my other answer here about Cordova and hybrid apps: Beginning with Apache Cordova
If the game runs completely in HTML5, I think it would be easiest to just use that one codebase and integrate it with Cordova and then deploy to the various platforms - why rewrite the app twice if you don't need to?
However, if you are using native device functionality, you may need to develop your own Cordova/Phonegap plugins for use. This way, you can call regular Android/iOS code (Java or Objective-C code) that you write from your web app code with JavaScript. This might be more work, especially if you have never written in these languages.
Personally, since you already have a working HTML5 app, I'd just try to get it working with Cordova and see how it performs. If you really need some native specific stuff, then I'd try creating that "stuff" as a plugin. Rebuilding the app twice, once for Android and once for iOS seems like a pretty big waste of time to me.
The answer here is either yes or no.
Yes if you want to use some specific feature of the native code. For instance, iOS's default objects is beautiful itself, you can easily drag and drop it to build your application. However, it takes lots of time to rebuild for another platform. Specially, if you intend to create app/game for multiple platforms, it would be a nightmare.
HTML5 is much faster for you to approach several platforms. However, you can't get the best result on all platforms and all devices. I mean, it is really difficult to bring the max performance of the app on all devices. For this solution, I suggest HTML5 with some libraries such as LimeJS, Crafty, Impact, etc. or some tools such as Construct 2, etc. I used to use HTML5 with all those libraries but found out that Construct 2 is much better.
Instead of using phonegap, I recommend cocoonjs. Specially if your targets are iOS and Android platforms.
Hope that help.
Yeah, even the simplest game such as bubble buster would be difficult to make cross platform with different version of android webview and you need cross platform? I would suggest looking into something like Unity3D.
This month I started to play with Flash Builder because I don't have a mac to create native iPhone apps.
I have made a Flex Mobile Project and an AS3 Mobile project. Both do mostly exact the same and I see great differences in operation speed (AS3 version is much faster). Also the size of the AS3 version is less than the size of the Flex version when I deploy the project.
But one thing disappoints me, the size of a deployed AS3 app (Android) is still about 8MB. I think that is quite huge for a simple app, or is it normal? I did not test the iOS version because I am not an Apple Developer member (is there a trick to deploy an iOS app with fake certificates)?
Resources I have used in the apps:
Two images approx. 35kb in size
A StageWebView
I want to know:
What is the average size of a simple app when it is a native app (apk file)?
What is the difference between an AS3 app and a Flex app except the libraries that re used?
Is the AS3 app converted to C or another language?
Why is the apk so huge (IMO)?
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
Thanks for the answer(s).
What is the average size of a simple app when it is native app (apk file)?
I have no idea. When you were comparing sizes; did you export a release build or a debug version? The full version of my app; using Captive Runtime is 12MB. That includes all the embedded images. I thought that roughly 8MB is the size of the embedded runtime. Of course, if you don't use Captive Runtime then the app will be smaller; but it will have a depency on the user having the runtime installed.
What is the difference between an AS3 app and a Flex app except the libraries that are used?
For all intents and purposes nothing. The Flex Framework will need to execute code to setup the framework and such. In theory this 'impact' is offset by the value that the framework brings.
- Is the AS3 app converted to C or other language?
Not for Android or Playbook. It relies on the Mobile AIR Runtime--which I assume is written as a native app somehow. For iOS there is a more in depth conversion taking place; but no on knows the exact magic sauce; but it the process is much more intensive than Android or Playbook and people believe that your code and the AIR Runtime is converted to Objective C somehow in a way that is not in violation of the Apple licensing agreement.
Why is the apk so huge (IMO)?
Huge is open to interpretation. Without seeing your full app code; it's tough to judge.
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
I don't think so; although there may be possibilities on unlocked devices.
You would like to use Mobile AS3 Project if you want you apps to be smaller and your GUI mainly contains vector graphics and Mobile Flex Project if you prefer to use standart GUI Controls that comes together with Flex framework but adds overhead in size because of controls that come with it.
As of the other questions:
the size of the apps is different on mobile platforms. Typical iOS app is about 2MB - 20MB. It really depends on resources you store with your app. What might be important to you is not to overcome 20MB if not needed because 20MB+ apps require Wi-Fi connection to be downloaded.
(However you should export release build version only as mentioned by www.Flextras.com)
there is no fundamental difference between AS3 and Flex apps - they both compile to the same instructions that executes on targeted mobile platform.
as far as I know (being iOS developer myself) there is no workaround to deploy an iOS apps. You need to use Mac and become Apple Developer to deploy with valid certificate.
to make your app smaller try to pai special attention to the resources you add to the project. Although I believe the size is so big because of framework itself, you would like to use more vector graphics vs. bitmaps when compiling apps with Flash/Flex.
When you export for Android you have an option of embedding the air framework in the application, that way your users don't have to download air. you can export your application without air embed which will result in a much lighter application, however your users will need to download air runtime. http://cookbooks.adobe.com/post_How_do_I_create_an_AIR_application_for_Android_tha-19299.html
I have a new project starting up that consists of building a webapp for a workorder based system. The main views are:
Viewing all open/closed/hold work-orders,
View Detail of Workorders
Create new Work orders
Account management.
In addition to being a webapp, it should also function as a mobile app.
What is the best approach for doing this? Will i have to develop a separate app for the mobile side? Can i use my webapp + sencha, jquery mobile, something.. that can work with my logic, classes, HTML structure to have it effectively work on mobile?
Or do i develop a mobile version first and think about progressive enhancement to the webapp (website)?
This question is open to all interpretations of flow, process, technologies.
Thank you Stack Overflowers.
Seperate out your business logic and model code from the view layer. Then use sencha touch and Extjs to create both a web and mobile (mobile web atleast) application. You can then reuse the model and business logic code and use the different frameworks to manage the view. When you have a mobile app running, use phone gap to turn it into a full-fledged app (assumming you need access to phone only systems (camera etc)).
We've done this with our own custom framework built on top of Ext and Sencha. We use ActiveRecord to run the models and then have a compile script that knows which files are for mobile and which are for web. We can then have all the code in the one repository and use the compiler to produce versions for the correct type (mobile or web).
It's definitely not a good idea to start with the mobile app, since web browsers are more ubiquitous than smart phones. Start with the web application and tailor the UI so that it can be easily displayed on smart phones as well as desktop browsers. If that's not a viable route, you could have a regular version and a mobile version of your website. In general, I think the overhead of writing a dedicated mobile client to browse your website is greater than the payoff unless you want to take advantage of the phones' hardware features like GPS or sensors (and even GPS you can still access from a web app using W3C geolocation api).