Any time I want to test out my app (and it's fairly large) I have to debug it on my smart phone. I cant use the mobile simulator built into animate because it has a bunch of ANEs that are dependent on Google Play Services. Is there a faster way to do this vs converting everything to ARM code every time?
Related
Sometimes, when I launch my game in LibGDX (the game doesn't require much power) the rendering is very laggy, but most of the time, when I run it the game runs smooth perfectly.
I would understand this if it would be laggy all the time, but it's laggy only in about 10% of the times when I run it. When I close it and run it again, it runs perfectly. Why is this happening?
I use Eclipse for launching and it runs as a desktop app.
I had the same problem. Try running it alone without Eclipse and it should work.
I experience this a lot it's not because of your libGdx project it's because of your computer. Computers just lag from time to time because of the multiple data or information they are handling everytime you're using it. Just ignore it man the important thing is you're making an awesome project, just don't mind the lag.
If you have a dual monitor setup, can you ensure there's no GPU activity on the other display? I noticed even with a decent setup, if something else was on my opposite monitor (eg., a chat client or a browser window) projects would run at a significantly slower framerate.
I've built a small demo application to test the GameInput APIs that Adobe released a little while ago. It works perfectly in debug mode, via the .exe and via the .swf that get generated via Flash CC, but when I test the application embedded on a web page, I can no longer use the controller (I am using an Xbox 360 Controller).
I've spent some time researching, and can't find any references to the GameInput classes either working or not working when the SWF is embedded on a web page.
Does anyone know if it is possible to get working (perhaps via some extra data in the HTML embed code) or whether this is an obstacle I won't be able to get around?
The GameInput classes absolutely work in the browser. Support has been there since Flash Player 11.8 (in beta), then officially added with 11.9.
It does come with some caveats:
Not all devices work; some fringe devices may get ignored by Flash.
Sometimes the addition of devices that are supported don't really work - you may have to disconnect and reconnect them to get them to work.
Sometimes when using multiple controllers of the same type they get mixed up and only one of them will work.
Actual reported control ids vary between the Plugin/ActiveX version of Flash (Firefox/Safari/IE/etc) and Pepper (Chrome).
You usually need to press a button with the proper SWF focused for the GameInputDevice to be detected and reported.
An XBox 360 controller is guaranteed to work. That's FP's main "target", if such a thing exists. I have personally performed dozens of tests with different devices and the (wired) XBox 360 controller is the only one that never gave me any headache.
I have a published SWF that works for testing which devices have been properly detected, and their reported controls, with source code available as well.
As a final note: as is the norm with any HTML-embedded SWF, be sure to always test in a server, not using file:///. A local server with XAMPP or whatever will do. Loading SWF content without a server always gives you a lot of restrictions that you have to circumvent and it's generally more effort than it's worth. I wouldn't be surprised if GameInput support was unavailable for SWFs loaded from file:/// on some given browser.
I'm new to mobile development and am looking for a hybrid framework for a few reasons:
Faster development: I don't need learn Objective-c/java or install XCode/Eclipse
Easier to iterate: We're a startup, and need to do a lot of A/B testing as well as iterate quickly. We want to be able to update the app without having to wait for app store approval and for the user to update the app.
Trigger.io solves the latter point - https://trigger.io/reload/ (which is a big plus)
Aside from that, what are the main diffrence between them in terms of (a) learning curve, (2) native UI feel, (3) performance
I originally asked the questions - gonna share my experience so far.
I started with PhonaGap and then switched to Trigger.io. Not necessarily saying that trigger.io is better - my main 2 reasons for switching were:
Trigger.io compiles much faster (seconds vs minutes). When I was using phonegap, I was testing my changes using Ripple stimulator - compiling the code after every small change was simply too time consuming. Making sure that your code runs on Ripple is a headache, and when thing didn't work on the device it took forever to debug. With trigger.io I can easily test every single change on the device.
Trigger.io allows pushing new changes to your release/app store app (instead of waiting for the users to update your app). To me it is one of the key advantages of HTML5 over native.
Some other notes:
Trigger.io provides only mediocre customer support (I have a paid account). Not sure about phonegap
Phonegap has much better opensource support and and way more plugins. With trigger.io if the functionality is not provided by one of their modules, or if you have a bug, you're on your own.
I work for Trigger so I'm going to represent our side of things.
Trigger is particularly focussed on making a good experience for people who don't want to see the native code and just want to write HTML/JS (we do also support native modules, but we hope that the majority of users won't need to write their own).
In terms of learning curve I highly recommend just giving Trigger a try, we have a free trial and you can be running an app in a simulator or on your device in under an hour.
For native UI Trigger has several modules which add native UI components. For example: https://trigger.io/modules/topbar/current/ and https://trigger.io/modules/tabbar/current/. I'm not sure exactly what is available in Phonegap so I can't make a direct comparison. On both platforms however with modern devices its possible to create very nice UIs with just HTML5/CSS.
As for performance both platforms are similar, depending on your app you may run into some limitations with HTML. For example, graphically intensive games are unlikely to work very well. Normal applications, however, are generally not a problem. See https://trigger.io/examples/ for some examples of what can be achieved.
I am developing a game using PhoneGap iOS. I integrated Ads in it using Mobclix as well as iAds. Also I integrated Flurry in the game for analytics.
But after integrating Ads in the game I am facing some performance issues in the game on some devices. They are as follows :-
Ipod touch :- Slow response to touch events, Animations are too slow, Rendering has become slow.
Iphone :- Animations are slow but better than Ipod touch.
It works fine on Ipad.
I have used PhoneGap to port our HTML5 code on the devices.
I checked Removing the Ads and Flurry Code then game runs Fine. I also searched extensively for this problem, but couldn't find a suitable answer. Looking forward to getting some help, here.
I've noticed (from first hand experience) that the Flurry HTML5 SDK can slow your app down, massively. It communicates with the server by inserting SCRIPT tags into the HEAD section of the DOM, which has three drawbacks that I can see:
Some browsers (e.g. mobile Safari on iOS it seems) will wait for HEAD scripts to resolve before running any other scripts
If you make multiple Flurry calls, you'll soon reach the browser's concurrency limit for multiple downloads from the same server, since each call creates a new SCRIPT tag.
The script tags are never removed, so the DOM keeps growing.
One solution is to try the native Flurry SDK for the phone(s) you are targeting, but that's not an option if you are supporting browser WebApps, and increases your development time & download size for native apps.
I find it pretty shocking that the Flurry HTML5 SDK is so inefficient. Back to Google Analytics I guess.
I'm looking to develop a mobile app which is going to help people find out whether a train is going to go to a particular platform or not.It is very simple. I know the timetables. I'll be making database of train timings and compare with the timings of user, when he uses the app and tell him, if the next train coming at the station he's at, is going to this platform at location X or not.
There won't be any fancy UI. There would be a dropdown of all stations. That's it. Response from the app will be going to platform no A. I don't know if I will include any feature as of now. The requirement that I see is, app should be offline and platform agnostic.The database entries are fixed and if they change then I should be able to give a new update.I have been reading about HTML5, but I don't want people to use the Internet for this. It should be available on Nokia phones,Android phones, Blackberry,Apple in that order.
Offline and platform agnostic will be hard to combine, unless you use one of the toolkits that pretend to do this (we started that way, but reverted - cost more time to chase bugs in the toolkit than to write code). Easiest is you give up the first requirement - most people with smart phones will have data bundles anyway, a tiny query is not going to make them frown.
Assuming you're not dropping the requirement, HTML5 for the UI can still be an option as most platforms let you embed the browser in your app. That way, you'd only need to port some small wrapper code and the business logic. If it's a commercial app, pick one or two key platforms (that will give you the necessary user feedback to make your app better) and outsource porting of the rest.
This is a tough one... I'd choose native programming. Id just have all the different platforms linked so they use the exact same database. Unfortunately, they all use different programming languages. I don't know about Nokia or Blackberry, but Android uses Java (or C# through MonoDroid) while Iphones/Ipods use Obj-C (or C# through MonoTouch).