Right now I only know about Scientiamobile's WURFL and a few others. Those libraries or databases tell you quite a lot of things about the device but none of them can clearly indicate that you shouldn't use CSS transitions or other sorts of animation because even if the device supports it, its a complete different story that those features will run smoothly and this is my major concern when building mobile web apps.
Is it technically possible to 'classify' devices in this direction, using the 'WURF' database ? And which device capabilities I should use to 'group' devices as 'fast' in terms of graphic power ?
Finally, I just need a rating of the device from 1-5 in order to decide which gfx operations I can use.
well, any thought is welcome. It turns out as real brainer and the researches on internet didn't bring up anything useful except lots of data about device caps.
Update-1 : I just got a response from ScientiaMobile : "we have been playing around with the idea of some form of Javascript performance index (possibly based on one of the existing benchmarks) that could give some indication of that, but we are still not there yet. The problem is complex."
Update-2 : The biggest bottlenecks we discovered in mobile web apps
animation power
PNG transparency
text and box shadows
image resizing
For us its really enough to figure out that we need to disable those features as they can bring any application to its knees. Possibly, there are also other approaches.
Thank you.
Unfortunately, I do not believe this is possible today for the general case.
If you are only interested in a limited number of devices, of course you could test each and target those specifically via user agent or JavaScript-based detection.
Within the context of a thick app (e.g., you "wrap" your web site with something like Apache Cordova), it would be possible to provide JavaScript access to some of the device internals (e.g., amount of total memory, amount of free memory, processor speed), but otherwise, this information is not available from the browser. As you've hinted at, having access to this type of device information may still be insufficient (e.g., seemingly "high spec" devices that perform poorly).
JavaScript feature detection libraries like Modernizr can answer whether something such as box-shadow and text-shadow is supported by the user's current browser, but does not provide information about how well or how quickly supported features will be rendered.
Likewise, the datasets from Browserscope and related project ringmark (somewhat of a JavaScript analog to WURFL) answer these browser support questions on a per-browser-version basis through crowdsourced benchmarking tests (e.g., does the iPhone support CSS3 transitions?), and for the general case, this is what would be necessary. You would need to run a benchmark test for the various features in question and assess real-time performance. However, even this has its limitations:
Because the necessary conditions for speed (available memory, processor, battery, network connection, etc.) are constantly in flux as mobile users move around, receive calls, change hardware settings, launch background applications, etc., the result of the benchmark is likely to be unreliable/unrepeatable.
Benchmarking takes time and will invariable add a (hopefully unnoticable) delay.
Depending on the feature, benchmarking may not be practical.
Features may behave differently in combination (e.g., animating transparent PNGs with shadows) or at scale (e.g., every image on the page is animating) than individually in the benchmarking test.
If you rely on benchmarking datasets instead of performing your own real-time benchmarking, the sample size, scope, and age of the dataset greatly limits its usefulness.
A final point is that I haven't even addressed is the fact that performance is rather subjective. Say it were somehow possible to assess/predict the speed of an animation. If the animation will run at 15 fps, should the user see that animation? What about 5 fps? Who gets to be the ultimate arbiter that decides the threshold for whether or not a given feature performs well enough?
The best advice I can offer today is to reduce (or eliminate) your reliance on the troublesome features for the time being. It may seem terrible to suggest going back to "the old way" of using images with precomposed shadows or making background gradients without CSS3, but at the end of the day the user experience should take precedence over using the shiney new technology. Many mobile devices are simply not there yet, and neither are the detection methods. If you must use these features, perhaps consider a simple but unobtrusive way for users to opt-in/opt-out like Gmail's "standard" vs. "basic HTML" view options, or consider automatically doing the opt-in for known good browsers.
I can't add much more than 'user113215' already said. Also its not an answer to the actual question but rather to the actual problem :
I did experiment with a few users and we were using a simple welcome popup menu, asking the user to turn off special effects such shadows and animations. The most of the test users did appreciate the choice and clearly understood the means of such menu. We do integrate this now more advanced and in conjunction with a hidden benchmark for auto pre-selection of GFX effects.
Thank you.
g
In short, no. How we define the smoothness of animations and graphics is solely depend on the FPS(frame-per-second). And in this question we are talking about "web-app"s, which are making use of HTML and JS on the client-side. Since none of the client side provide interface for the programs to get the FPS by HTML or JS, it is impossible to tell if the client is smooth or not.
However, if you really want a benchmark on the performance of web-app. You can make use of stats.js to monitor the change of stat and have a benchmark for you to suggest your client activating or disabling any sort of effects on runtime. This method even working with most FXs of Javascript libraries like jquery too. But this will take sometime for you to get enough data before applying changes and the stat may differ from the status of the device, such as memory usage, concurrent applications, etc.
Related
I would make an application that handle the volume buttons when screen is off. The goal would be to turn on or off the front LED.
I know that there many topics here that talk about it, but the recommended solutions (like PARTIAL_WAKE_LOCK) seem to be energy intensive and drain the battery very quickly!
What I want is a solution that is as energy efficient as possible. Is this possible? Maybe some kind of hooking?
Please note that the solutions based on scheduled tasks can not be envisaged for this project because I want detect keys in real time (or close to it)!
Take a look at this question.. if you already haven't ..
Just to make one thing clear. If something is not documented in API docs of android then any hack or workaround you find won't be reliable as Google may decide to change things in future releases, for example there is nothing documented about creating shortcuts after the app is installed ! But Since Android source code is available, developers took that piece of code as how was playstore creating shortcuts.. but its not documented so Google may change it in future !
Quite simply as the title states, is it possible for Java to read what is happening in a web-browser based Flash game?
For Example: Could I make a Java program which could play FarmVille for me by reading what is going on currently and make decisions based on a pre-determined set of actions?
FarmVille doesn't publish any sort of API, and you won't be able to access the RAM allocated to the Flash player (to my knowledge), so your only real course of action is to analyze the screen and automate input. In other words, there's no prewritten farmville.getUnplowedCells() to use, but you can write a program that takes screenshots, analyzes them to find the unplowed cells, and then generates the mouse/keyboard input that would make your character plow his unplowed cells. The Robot class can be used for this sort of programming.
This would be very time consuming and probably not worth the effort. Also as a side effect this would essentially "take control" of your mouse and keyboard and prevent you from using your computer normally. However this problem can be mitigated by running the program in a virtual machine.
No, there is no implementation for a Java-Flash bridge that allows anything more direct than IPC. Your best bet is decompilation (which would probably require deobfuscation) of the swf and interaction through common IPC mechanisms.
You could also tackle this using a different approach by recognizing elements on the screen by their pixel colors, for that you could use the Java Robot API which provides you with access to the keyboard, mouse and video. Since FarmVille is a 2D game, recognizing elements on the screen should be fairly straightforward -- performing image comparison, or partial image comparison (just the image's borders or a representative part) to increase the speed.
Aside, cheating in online games is not a nice thing to do and you can probably find activities that are more productive given you are smart enough to make software that works.
If you goal is to make a bot for FarmVille, then you're heading a wrong way. Keep in mind: it's ONLINE game. So, you don't have to read flash client's state, it'll be much more better, to read incoming packets, you don't have to simulate mouse/keyboard events in swf - just create correct packets, discribing your in-game actions. So I recomend you act like this:
1) Write a sniffer in Java (it's quite easy, because you have to write a simple one, not an ultimate tool, like Wireshark).
2) Use request's analytic (such as Firefox's Firebug) to catch some packets from your game. Reading them, you can retrieve all info, what you need: packets headers, game actions encoding, etc.
3) Code logic in your Java program: read incoming game packets and execute actions, sending requests.
4) Set user-agent options of your connection object similar to a popular browser (if you refuse doing that, game server may ignore your requests).
That's all. Remember: a game bot isn't an image recognizer, it's just another game client, with another GUI and logic.
P.S. If I misunderstood you, and your goal is to create a webpage with flash and applet, which comunicate with each other, you have to use JavaScript as a mediator between them. Flash calls JS using ExternalInterface.call, JS calls applet and vice versa.
So, I have been exploring many similar questions across website (this, this and this and many more). People wanting to implement their own custom lock screen (not talking about widgets). So far there have been two implementation techniques which users are using.
Home Screen Replacement. In this technique its suggested to create a home screen application, where after unlock logic the default screen shows up. I believe that in this situation developer has to disable Home, Search, Menu and Back button when the lock screen is visible and to implement the Screen off-on logic.
An application. In this technique a normal app is made where after unlock logic the default screen shows up. I believe that in this situation developer has to disable Home, Search, Menu and Back button when the lock screen is visible and to implement the Screen off-on logic.
Now, I don't understand that what is the difference between two approaches? StackOverflow community seems to stress more on the home screen replacement technique. I am very new to Android development so I might be missing some aspect about it. Please suggest that which approach should I use and why? (also, which is easy?).
Thanks so much!
I would use the first method, but only for usability reasons. Because it gives the user a choice to easily revert back to the original homescreen/lockscreen if he chooses not to make the new one a default choice yet.
I'm afraid both strategies you described are quite difficult (depending on the api level range you want it to work on). The difficulty is not in their difference, the difficulty is in overriding the buttons (as Google makes it more difficult by closing down security loopholes for the newer api levels).
PS: Please note that Jellybean has a new Daydream functionality. If customizing the lockscreen is all you need. That may be the way to go since Jellybean is much more secure in that respect and more difficult to work with than the previous api levels otherwise.
Also, consider using the HTC screenlock api for HTC devices. This way, your solution won't be too hacky at least for their newer devices. And perhaps, do a version for rooted devices as well, since that too should be easy, for users who already have obtained root on their device. Don't discount the rooted market, users with root access do spend a disproportionate amount of money on applications in Google Play. That much is obvious if you just take a look at some of the rough numbers of downloads for paid applications that say (for root only) that Google Play gives you.
After downloading and using Xuggler, my initial impressions are very good; it supports a whole host of codecs, it was relatively hassle free to get going and the getting started tutorial videos explained all the necessary concepts very clearly.
However, after playing around with it for a couple of days I'm really tearing my hair out over getting all the audio and video to sync up nicely. It's fine when playing normally but when adding pausing, seeking and accounting for occasional 6 second pauses while my external hard drive spins up it becomes an absolute nightmare.
I've partly implemented something already but it's nowhere near perfect - you can seek around a few times but after a while it still drifts off.
I can't help thinking this is a common use case of Xuggler and someone must have done this sort of thing already much better than I have. But alas, I can't find any examples beyond the ones on the website. Is there a higher level API around that manages all the audio / video sync issues and just provides some higher level controls (play, pause, stop etc.)? I've no problem going down the route of doing it myself if there's nothing out there already, but I've never been a fan of reinventing the wheel (especially if my new wheel is in all likelihood worse than the old one!)
This is really a two part answer - the first being yes, there is a higher level "player" framework here. It's in early stages but much better than anything I would have cobbled together quickly, and I'm sure the guy running it would be open to any improvements in the code.
Secondly, I didn't really go with the above at all because I looked to VLCJ instead which uses libVLC which in turn has all the synchronisation stuff built in nicely. To get multiple players embedded in the application reliably you need to use out of process players (see here for how I went about doing it) but once that framework is in place it works reliably, fast and overall very well.
When considering a platform for a game, I've decided on multi-platform (Win/Lin/Mac) but can't make up my mind as far as browser vs. desktop. As I'm not all too far in development, and now having second thoughts, I'd like your opinion!
Browser-based games using Java applets:
market penetration is reasonably high (for version 6, it's somewhere around 60% I believe?)
using JOGL, 3D performance/quality is decent; certainly good enough to render the crappy 3D graphics that I make
there's the (small?) possibility of porting something to Android
great for an audience of gamers who switch computers often; can sit down at any computer, load a webpage and play it
also great for casual gamers or less knowledgeable gamers who are quite happy with playing games in a browser but don't want to install more things to their computer
written in a high-level language which I am more familiar with than C++ - but at the same time, I would like to improve my skills with C++ as it is probably where I am headed in the game industry once I get out of school...
easier update process: reload the page.
Desktop games using good ol' C++ and OpenGL
100% market penetration, assuming complete cross-platform; however, that number reduces when you consider how many people will go through downloading and installing an executable compared to just browsing to a webpage and hitting "yes" to a security warning.
more trouble to maintain the cross-platform; but again, for learning purposes I would embrace the challenge and the knowledge I would gain
better performance all around
true full screen, whereas browser games often struggle with smooth full screen graphics (especially on Linux, in my experience)
can take advantage of distribution platforms such as Steam
more likely to be considered a "real" game, whereas browser and Java games are often dismissed as not being real games and therefore not played by "hardcore gamers"
installer can be large; don't have to worry so much about download times
Is there a way to have the best of both worlds? I love Java applets, but I also really like the reasons to write a desktop game. I don't want to constantly port everything between a Java applet project and a C++ project; that would be twice the work!
Unity chose to write their own web player plugin. I don't like this, because I am one of the people that will not install their web player for anything, and I don't see myself being able to convince my audience to install a browser plugin.
What are my options? Are there other examples out there besides Unity, of games that have browser and desktop versions? Did I leave out anything in the pro/con lists above?
I'd suggest writing a game first.
It's easy to get caught up in how to make the best game ever,which can run on anything from an abacus to SkyNet, but the reality is that you're going to have plenty of challenges ahead of you just finishing a game that runs on your own PC.
Write a game first, for one platform (whether that platform is "Windows native with DirectX", or "Java applet" or even "pure AJAX in a browser"). If you can do that, then you can start thinking about how to port it to other platforms. But trying to do everything is a sure way to end up achieving nothing.
Or to put it another way:
I've decided on multi-platform (Win/Lin/Mac)
so you've actually decided nothing. Decide on a platform to develop on. Then make the game. Then make it work on other platforms.
Don't worry so much about what your "audience" will find acceptable. If your game is fun, then yes, people will happily install Unity. Just like they'll install your game if it's not browser-based. But the important point is not "what do I have to install to play it", but rather "is it worth it". Your focus should be on making a game that is worth the installation.
And unless you're planning to sell 20 million copies of the game and live off it, your "audience" doesn't really matter that much, does it? What matters is putting the game out there so those who are interested can try it.
But a single-platform game is a lot better than an unfinished cross-platform nothing.
A game that requires me to install Unity is a lot better than something that takes you an additional 3 years to develop because you insisted on reinventing the wheel.
Yes you can have the best of both worlds.
It's perfectly possible to write a Java application that will run in both an applet (for your online users) while also running as a standalone application in downloaded form.
The key technologies are:
JNLP
JOGL for the graphics, which also has some good demos
I'm not so familiar with it but I think jMonkeyEngine looks very promising if you want more of a full-featured game engine
If it's any use, an old game I wrote called Tyrant supported running both as an applet and as a standalone downloaded .jar file, all the source is open if you want to look at it. This used simple AWT rather than 3D graphics.
And finally here's another example of converting an applet into an application with a pretty minimal amount of code.
If you really want that kind of penetration then I suggest HTML 5 + javascript depending on the performance you need.
First of all you start with the wrong question. Your decision for a technology should be driven by the concept behind the game. It seems that you are sure about the idea to write a game - so ask your self what the requirements for the game are. This will lead you to your technologie. If it doesn't get an idea of "what" you want to do.
To your Pro's and Con's:
Don't focus on things you will never need or be able to use. Thinking about the steam platform isn't interesting for a hobby developer. Also android isn't interesting if you are not really want to ship your application for android. This Pro's will actually never be a pro in reality.
To sum it up: Let this decision be driven by your idea, not the technology itself. If you have a clear idea of what you want to do you will get your answer.
(And btw.:
Think about what browsergames imply. Behind a Browsergame there is a huge service-area, only for keeping the game running. Companys working in such areas are basically service-providers.)
You might want to look into Google's Native Client, which allows you to write your application in C or C++ (or anything else that compiles to native code, really). A new feature coming to the SDK is LLVM support, which will (hopefully) allow NaCl software to target any platform that Google's Chrome browser runs on (or any browser that the NaCl plugin works with - currently x86 and ARM are supported, IIRC).
You mentioned Android in your question - have you thought about developing the game purely for Android?
In effect you get the best of both worlds, easy to maintain, easy to release new versions, easy to monetize and get some small income and you don't have write your own installer or update mechanisms either.
Yes. You can make something that will work in both. Basically, make your program work inside a JPanel. The applet can display the JPanel, and the desktop version is just a window with your JPanel in it.
You could also have a full Swing (or whatever) GUI, which the applet launches in a new window when they click the little "start" button you'd have on your applet.
There are a few other differences you'll have to take into account, like possibly loading resources, but I've done it before for simple games I've made.
I don't think you can really compare the two:
In my opinion:
Applet, flash and other browser based games are typically small "toy" games either written for free or supplemented with advertising. For examples, check out the Addicting Games website.
C++ games are more likely to be heavyweight studio-written games relying on dedicated physics engines, graphics engines, etc (particularly true of games distributed on Steam I would have thought). The learning curve is likely to be much steeper, as C++ is inherently a more difficult language than Java / Flash.
If you're unfamiliar with C++ my advice would be to steer towards Java with JOGL. That way you can scale the Open GL learning curve before having to tackle C++.
EDIT
To address the other section of your question regarding implementing a game in both browser and desktop form, you could consider implementing the game in Java and deploying an applet and standalone version, whereby the standalone version can take advantage of Java's full-screen exclusive mode API. You could base both applications on the same codebase. You could also consider shrinking the applet's footprint size by retaining data files (e.g. game levels) on the server-side and retrieving them dynamically when required.
While WebSense won't let me browse directly to the site, for obvious reasons, the first thing that came to mind when reading this question is a game like Wurm Online. It's written in Java with JOGL, implements content streaming and local caches, and seems to have touched on a lot of the points you're interested in. It's a desktop Java application rather than being truly "in-browser" but I think you could still learn quite a bit from its implementation.
The in-browser game is always in peril of having its window closed or refreshed, causing it to abruptly lose state unless everything is being kept server-side. This means you either have very simple games that can maintain synchronization using a call/answer model (such as the myriad of Facebook "Mob Wars" text-based games) or risk an inadvertent bump of F5 catapulting someone back to their last "saved game."
I'm not sure that refusing to use a plugin because you personally don't like it is a sensible choice. This option lets you write you app installable as a desktop app, or a browser plugin (with not much extra work) and you still get to write it in C++/GL. You said you don't think your users will install plugins... why not? If they will install an application then why not a plugin which basically boils down to the same thing?
You could look at Flash too, which is gathering some 3D functionality and can run in-browser or as an AIR dektop app. But then users would need a Flash plugin, which you presumably don't have either.