App size increases for 11MB after implementing adMob ads - libgdx

I noticed that the size of my libgdx app drastically increased after implementing admob ads. Increase was more than 11MB. Is this normal?

Increased by 11 MB that big !! for my experience I only noticed 1 or 2 MB change, how are you using admob ?
if you are using like this as dependency :
compile 'com.google.android.gms:play-services:7.5.0'
you should know taht you are using every feature of Google Play Services, including location services.
if you only need ads try use this instead:
compile 'com.google.android.gms:play-services-ads:7.5.0'
also I recommend to use Proguard to reduce the size of APK by removed unused classes from the library, try add this in your Proguard config file
-keep public class com.google.android.gms.ads.** {
public *;
}
-keep public class com.google.ads.** {
public *;
}
good luck

It cannot be 11mb just because of admob. Make sure you did not add other resources (drawable) or libraries at the same time you added admob? To verify you can just try temporarily removing (only) admob and see of it really gets reduced again by 11mb. But I highly doubt that only admob related things would take 11mb.
Again by size, I'm assuming you are talking about apk size. And that is for what I say cannot be something like 11 mb of increase. But if you are talking about memory on storage used after installation then it is possible and there is nothing wrong.

Related

Google Web Designer has a very long load time

I'm creating an html5 banner using Google Web Designer. I've created the banner and published it. When I view the published version I noticed that it takes sometime to load.
Someone else on my team is also creating HTML5 banners. The banner that he creates loads instantly even though its a larger file size. We compared our files and other than the actual assets, the way the banner was created and published is the same.
Does anyone have any ideas why this might be happening?
GWD add this code at the end of the banner and animation show up immediately:
<script data-exports-type="dclk-quick-preview">studio.Enabler.setRushSimulatedLocalEvents(true);</script>
Which environment are you using?
When creating a new project in GWD you are able to select an environment. By default is DoubleClick.
This adds additional file (in the case of DoubleClick, the Enabler library).
If you open your Chrome console, while running the banner, you will see that the banner is not initialized until the enabler is available.
You will also see how much time it takes to load the enabler.
If your colleague is creating a banner without that library, or without correctly listening to the event Enabler.initialized, this may be the main reason for the discrepancy.
If you don't want to include this additional library (that is used to integrate your banner in DoubleClick Studio), just select Generic from the environments dropdown.
There is also another reason that may cause the delay, and is the PoliteLoader.
You can select to politeLoad the banner from the Publish menu.
If the PoliteLoader is selected this cause the banner to be initialized only after the page is fully loaded. This may cause delays compared to a non polite loaded ads.
This all seems not to be a bug, but a feature of enabler.js simulates a test environment, when not beeing uploaded to Adwords (guess it similar in Doubleclick). Uploading to Google Environments should change the situation
Look at the console and see:
There is a long delay in alle items loading after the enabler.js.
It is NOT because of a long loading time of enabler.js - thats all fine.
Looking at the Logs, the enabler waits a second and throws out:
[ 1.008s] [studio.sdk] Using default ad parameters in test environment. Simulating local events.
When uploading to Google Adwords (i assume that this all is similar to DC Studio) - the enabler throws out different logs and the delay disappears.
Hope this was helpful.
By chance, I found out a way to make the Enabler loading fast. Instead of using Publish, use Preview to generate the HTML.
For some reasons, Enabler.js in preview-generated HTML only takes 0.019s to load as compared to Enabler.js in publish-generated HTML taking 1.015s to load.
Studio Enabler SDK looks for "e" parameter in iframe URL containing Studio creative. It expects a number and uses that to set the creative environment.
Setting e=1 in your preview environment (query string parameter in the iframe url pointing at the index.html for your studio creative) will tell Enabler to use LIVE mode.
I assume there is a reason why Enabler has this functionality (avoid counting impressions or paying for impressions from test/qa environment)...so I wouldn't suggest using this as a permanent setting.

How to make the ScheduledTaskAgent start as soon as the app is installed?

How to make the ScheduledTaskAgent start as soon as the app is installed? I have seen a property LaunchOnBoot when registering the service in WMManifest file. I set it to True and does not seem to serve the purpose. Any ideas?
This is for updating a tile (Primary Tile). The tile need to be updated as soon as the user pins the app to the home screen.
You cannot to it. Your app must run when registering a ScheduledTaskAgent .
If you want this for debugging you may use ScheduledActionService.LaunchForTest(). Otherwise you can not. But the real question then would be why you need it other than debugging?

OpenGL plugin crashes Chrome when the visible region is changed

I'm developing a plugin using FireBreath on Windows (for now) that among other things is displaying a webcam feed using OpenGL. I'm using a windowed plugin and I'm drawing from a separate thread. The code can be viewed here:
Header file
https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.h
Source file
https://github.com/EvilTengil/kinect-at-home-plugin/blob/0007beecf136ff2e5e1aa50be94d4906447a8f43/Win/KinectAtHomeWin.cpp
(Ignore the strange code in onWindowResized, it's just some testing that remained in the commit.)
The problem is that as soon as the browser window is re-sized so that the visible region of the plugin is changed or the the extension is somehow scrolled outside the visible area of the scroll box, the plugin crashes in Chrome. I haven't got Firefox installed but I'm guessing it's a NpApi thing, since it's working in Internet Explorer.
I believe what is happening is that Chrome releases and creates a new HDC whenever the visible dimensions of the plugin is changed. This probably results in that the Rendering Context is invalid, but it is still being used in the plugin and that causes the crash.
I've noticed NPP_SetWindow get's called when this happens, but those calls are ignored in NpapiPluginModule_NPP.cpp, so my there is no way of hooking in to this event.
I've Google for several hours now but without finding any help. Does anyone have any experience of this?
I have an idea that it could work if I created my own child window to the plugin window where I could handle my own DC. I did some quick testing that failed, which is probably because of my lame Win32 skills. But could this work with some more work? Another idea I have is to track the visible region somehow, but I haven't looked in to this yet.
Windows handles getting invalid should not cause a program to crash per so. But OpenGL, namely its extensions require some special precautions, especially if the host program makes use of OpenGL as well.
Any kind of plugin or DLL that makes use of OpenGL must take care, that is puts its required resources into a sane state before using them, and put them back once done. For OpenGL this means, everytime before you start using it you should rebind your context:
HDC hOldDC = wglGetCurrentDC();
HRC hOldContext = wglGetCurrentContext();
// first unbind old context/DC from current thread
wglMakeCurrent(NULL, NULL);
// then bind our context
wglMakeCurrent(hMyDC, hMyContext);
// this is essential, as in Windows the addresses of extensions
// may depend on the active context, so you must reinitialise
// extension function pointers!
reinitialize_extensions();
/* NOW USE OPENGL FUNCTION
// cleaning up once we're done:
wglMakeCurrent(NULL, NULL);
wglMakeCurrent(hOldDC, hOldRC);
// remember that we also need to reset extension
// function pointers to the other context
reinitialize_extensions();
Since in Window extension functions pointers depend on the context it makes sense to put them into a structure and call them through that one. This saves the whole extension reinitialisation thing. In C++ you could wrap the whole OpenGL context in a class for this.
Remember that you need to go through this setup/teardown everytime your plugin gets called through NP-API.

Adobe Air - Open app in fullscreen

I created an Air desktop app with Flash CS 5. Usually Windows (XP) is opening an application (like Firefox) with the latest set size and position.
For my installed Air app it's always just the default one.
How to start it with the latest used size and position?
Thanks.
Uli
hope this will work for you:
http://cookbooks.adobe.com/post_Using_the_FullScreen_functionality_in_AIR-8004.html
http://blog.ochodurando.com/2010/04/adobe-air-e-fullscreen/
You need to save a record somewhere that remembers the window's size, and possibly position. If your app has a preferences file, this would be an ideal place to store that information. Then, whenever your app starts, it checks for this information and resizes the window if any values are found.
Most popular programs include this feature (and don't even mention it, since it's pretty basic UI), but it's done intentionally and not as a default for every application. Thus if you want it, you have to program it in.
You can read and write to application.xml. You'll find there and nodes.
file = new File( File.applicationDirectory.nativePath + "/META-INF/AIR/application.xml" );
Adobe restrict writing access to application diractory but this trick is useful if you don't want to create a separate config file in app-storage:/ folder, which is of course prefered.

How do I add an event to URLLoader Class?

Keeping into consideration the Actionscript 3 event HTTPStatusEvent:HTTP_RESPONSE_STATUS, which is ONLY AVAILABLE for AIR (and not Flash 9/10)
Quote from site:
Language Version: ActionScript 3.0
Runtime Versions: AIR 1.0, Flash Lite 4
I would like to add the same EVENT by extending the HTTPStatusEvent Class of Actionscript 3 for Flash (9/10).
I'm working on Adobe Flash CS3 and I'm trying to get the "last" location of a URL loader (I'm calling a php with a header("Location: ..."); ) so I need the location after it changes. This should be made directly by flash and I cannot use php proxies not other.
Also, I cannot find the source code of the AIR HTTPStatusEvent Class, which I need to get the event (specifically, the responseHeaders and responseURL properties that the AIR class has).
Of course, if you know of any other way to accomplish this, feel free to share it.
You can't do it this way.
Think about it: You are trying to add behavior to the URLLoader class by extending an event class that is thrown from there. Figuratively speaking, it's a bit like changing the paper size when you've only written letters to your next door neighbor, and now you want them to go overseas - unless you also give them to the mail main, that's not going to be very successful...
I've stumbled across a number of forum threads discussing this, and most of them seem to agree that Adobe prevented access to response headers in Flash versions prior to FP10 / AIR due to some sort of security issue. I'm not sure how much of this information is accurate, but I am quite confident that there is no way to get around this - you can't get the Location:header in older Flash versions.
You will have to find some other workaround. For example, if you have access to the PHP script, you could add an HTML comment containing the redirect location, and parse that value in ActionScript.
<!-- Location: http://google.com/ -->