As reported by some people on stackoverflow:
… video playback is broken under iOS8 in standalone apps (HTML pages added to the homescreen). This bug also effects players like Youtube and JWplayer.
Tests showed that the video starts loading but the video.readyState property will never be higher then 2 (data for the current playback position is available, but not enough data to play next frame/millisecond).
Here is my fastpace test:
http://www.4inloop.de/show/ios8-html5-video/ – open it on an apple device with iOS8, add the site to your homescreen, start the standalone app and hit the start button. (compare it with a normal browser like chrome or something). It even works normal on iOS8 safari – it’s only the standalone apps that are effected.
For now it looks like we just have to wait for Apple to fix this – the update to iOS 8.0.2 did not fix the bug.
Today I installed iOS 8.2 on my iPad2 and iPhone5. Unfortunately the bug is not fixed.
Today Adobe released the long awaited profiling tool “Monocle” at Adobe Prerelease. If you use Flashbuilder you can just compile your file with ASC 2.0 which is included in Flashbuilder with the parameter -advanced-telemetry.
But if you use e.g. FlashDevelop you have to utilise the Python script which is included in the download package of Monocle to make the swf file ready to be profiled by Monocle. Make sure you compile with the newest Flex/Air SDK (download here) and install the lastest Version of Adobe Air (namely version 3.4).
Then just compile your Air app so the swf file is generated in bin. Now use the python script like this: add-advanced-telemetry.py yourswf.swf
If everything works fine it says: Added opt-in flag with no password (as long as you have not added when).
Now package your app, install it, start Monocle and then your Air App. You are good to go to profile your app to the deepest!
If you have trouble using Concrete5 with XAMPP 1.7.4 and you get error messages like:
Strict Standards: Non-static method Loader::database() should not be called statically
…you need to change the following line in your /xampp/php/php.ini
error_reporting = E_ALL | E_STRICT
error_reporting = E_ALL & ~(E_NOTICE | E_STRICT | E_DEPRECATED)
If you have downloaded the project template for Flashdevelop: http://blubl.geoathome.at/wp-content/uploads/2010/10/091-ActionScript-3-Android-AIR-AS3-Projector.zip
… put it in the flashdevelop/projects folder. Now you can select Android/Air app in the “new project”-screen. The template contains a good readme.txt for what you need to do.
Additionally you have to setup the compiler options and setup the custom path to Flex SDK. Also start adl.exe with the parameter -runtime to lookup the version of it. If it says 2.6 you have to change the application.xml accordingly.
Otherwise adl will quit its job telling you: Error while loading initial content. Now you should be able to test you apps in FlashDevelop.
Changing Screen Size
If you want to change the screensize in which adl opens your app go to project settings and edit “run custom command”. Change it to:
$(FlexSDK)\bin\adl.exe; -screensize 600×1024:600×1024 application.xml bin
The second resolution is for fullscreen mode and needs to be set for adl to work.
I want to point out some reason why Robotlegs makes sense. For someone who does not know Robotlegs: It’s an Actionscript 3 framework that builds upon the Model-View-Control (MVC) code design pattern. In short: You can use it to seperate the logic of your application (controller) from the data (model) and the representation of it (view).
You can find implementations of MVC in divers frameworks and programming languages – frontend and backend alike. When you google MVC pattern you can read tons of articles about the pros and cons.
Communication between Objects made easy
Beside MVC there are two other features I really appreciate about Robotlegs. First, it has a build in event bus. You should know events from Flashs Display List. Objects that get created if the user “does something” with the user interface (e.g. MouseClick). These event objects can bubble up the display list (the hierarchy of nested displayobjects like Sprite or Movieclip). Thats nice as it is but the events are bound to the displaylist. In Robotlegs the objects share an eventdispatcher they can utilize to listen for events or to send events into the framework – and that is not limited to user interface elements nor the displaylist. The benefit is: You do not need to know the actual object that broadcasts the event meaning you do not need a reference to the broadcaster in your listening classes. Just listen to the event bus and everything works.
Robotlegs helps to reduce code
The other thing is automated Dependecy Injection (DI). (Google it for more information). What automatic DI does is it provides your classes with their dependencies. If you have a Car class and that class needs an instance of the Motor class to work properly when getting instantiated Robotlegs does it for you. That means you do not have to write construction code to first get a motor, instantiate it, then create a car and put the motor in it’s constructor. Code instructions like that are called boiler plate code, code with the sole purpose to create and combine objects, code that has no business logic. Sure you have to instruct Robotlegs on startup what objects are created at what time but that is, compared to manual creation and combining, a lot less code.
And it does not make it harder to understand
Some say using frameworks like Robotlegs bloat your code and DI makes it hard to understand what happens where. But these arguments are even more true for individual code. I had to get back to my last bigger project built with Robotlegs after 2 month. I found it really easy to put in new functionality because of the seperation due to MVC and DI. I just wrote another class, pointed out that this class needs an instance of the model when instantiated and was ready to go. Without Robotlegs I would have needed to break apart my code base and look for hooks in my code to put the new class into place – more boilder plate code or even restructuring other classes.
Robotlegs or other frameworks are not made for very very small projects like banner advertising because they naturally put in some kB for the framework classes but if your project is not restricted in that way give it a try. It not only makes your code more flexible but makes you think about object communication in general.