On iPhone5 [[UISCreen mainScreen] bounds].size comes back as 320x480. Why. In all the posts I'm reading, people are saying that it returns the correct screen size. What is going on here? Am I missing something in the .plist file or something?
BTW I am hand coding the GUI, so there is no XIB.
Unless your app includes a Default-568h.png in it's bundle, it will run inside a 480 point high legacy screen sandbox on the iPhone 5, and can't draw or see any dimensions outside that sandbox.
Note that including this Default-568h.png is only allowed when building an app using Xcode 4.5 and the iOS 6 SDK (or, presumably, later) for submission to Apple's App store.
Added: When building with the iOS 8 SDK (or later) and running the app under iOS 8 (or later), a LaunchScreen.xib will also remove the 480 height sandbox.
It would appear that having a launch image in place is a prerequisite to [[UIScreen mainScreen] bounds] working properly on iPhone5. This is an issue for those of us dependent on design teams for our images. It looks like you just have to hack together a launch image and put it in place.
Is there really no better way? Anyone?
Related
I got my feet barely wet with codename one 6 months back or so. I just upgraded to latest and am following some tutorials which are not explaining how to make the text so I can actually read it.
More specifically, I bought the book Creating an Uber Clone In 7 Days before sketch
My pictures are definitely not matching the books pictures without doing some guessing and extra work for some reason.
Right out of the gate, the empty template shows this in the designer(and the phone simulator is the same).
That picture is a little zoomed in meaning it's even smaller on my monitor!!!
I also tried just my macbook pro turning off my 32" screen to make sure it wasn't just from me doing it on a huge monitor. Same exact results, same size. It's like an old 90's game with it's old school graphics.
any ideas how to fix this? or do I just modify the "[Default Style]" which was checked to 'Derive'. If I modify it to from blank to native:MainThin AND size Medium to millimeters and finally 12 to 7. ps. What's the 12 even mean if 'Medium' is selected. Seems like 12 should be grayed out if Medium is selected(I think).
Any ideas on this? Until then, I am just going to use 7 mm I think. Seems to work much better although, there are still some VERY hard to read lines of text. Not sure why those fonts are not changing. For example, read the text "This is a Label" which is very very small below...
EDIT: This is a picture of eclipse 2019-12 / codenameone 6.0.0 and notice the design is previewing the incorrect sizes while the simulator(on the right has the larger sizes)
thanks,
Dean
The design preview has different density from the simulated device. As such the preview in the designer will show the fonts as they would look on a low density device unless you significantly increase the screen size to match that of the simulator (which won't leave much room for the design itself).
The size in the simulator is the thing that counts, I'm not sure why you see a major difference between the eclipse and intellij designers. Both should use the same designer jar file that's located in your ~/.codenameone directory.
I can't upload my app build with codename one anymore.
I received a mail from Apple
Missing required icon file - The bundle does not contain an app icon for iPad of exactly '167x167' pixels, in .png format for iOS versions supporting iPad Pro.
What should I do ?
Thank you !
This is due to a regression with the new xib mode changes mentioned here.
Try using the build hint ios.generateSplashScreens=true to work around the issue. I suggest removing this hint next week as a fix for this regression will land.
See https://groups.google.com/d/msg/codenameone-discussions/GKomhHhuCz8/K9YC41DFAwAJ
my current project requires the implementation of Google StreetView.
The app already exists for iOS, where everything worked pretty fine, StreetView is embedded in the view, customized with overlays and buttons and what not...it runs fast, scrolling the StreetView view is smooth, it's obviously no webview...in short, it's perfect.
Now I have to do this app for Android and I was looking all day already, but with no success. From what I found out, there is the possibility to start StreetView as a new activity, without any chance to customize it, no overlays, no buttons, just standard Google stuff. This should be pretty smooth as it is not a webview. I can't use this, as I have to customize the UI.
Now I tried the webview approach and this makes everything slower and more laggy than you'd expect from even Android... BUT...seems to be customizable. Still, as slow as it is, I can't imagine anyone having fun with it.
So, my question is, do I have any more chances to get this working (a transparent Activity on top of the StreetView Activity? - please no)? Why does Google get it right for iOS and not for Android?
The iOS SDK just got released recently, is there a chance a new one will be coming for Android soon?
Thanks for any hints, M.
Found it. The answer lies herein : Android webview slow
Turning off the hardware acceleration speeds up the rendering ... yeah, right!
if (Build.VERSION.SDK_INT >= 11){
webview.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
}
I have been handed over a Silverlight 4 application that uses the Google Earth API. We have an issue with newer versions of Google Earth: In Internet Explorer, the map displays as a white background with the text "ATL 10.00". In other browsers, the background is just white (cannot see any text).
It works with Google Earth version 6.0.3.2197 but not in any version after that.
I have read this thread
- but none of the suggestions there worked. I must note, though, that the JavaScript code for initializing GE in Silverlight is rather complex, but as far as I can se, the initialization of GE is done in the google.setOnLoadCallback function.
It would be nice, if someone knows what exactly the "ATL 10.00" message means.
Any help would be greatly appreciated!
EDIT
Please let me know if I should clarify in further detail.
UPDATE:
The problem was caused by 2 things and probably a combination of the two:
1. The container for the map was added dynamically with JavaScript into another div
2. The container's width and height was set to 0 in order to hide the map.
So, the solution for me was to render the containing div together with the rest of the DOM. In order to "hide" the map, I positioned it absolute beyond the bounds of the screen.
Hope this can guide others to solve similar problems.
ATL in referring to the Active Template Library in Windows. ATL in Windows is a set of template-based C++ classes that let developers create COM objects (rather like MFC and ActiveX).
10.00 here simply refers to version of ATL being used. Seeing it probably means that the COM object (GEPlugin in this case) has not been created or initialised properly in the browser. The blank screen with the version number in the centre is what the plugin looks like before it loads content.
So, it is not really an error message at all - indeed one could say it is really the failure of an error message to appear that you are seeing.
Anyhow, to answer your question in simple terms it means than the version of ATL that was used to create the plugin was version 10.00.
In practical terms it means that the plugin failed to initialise properly for some reason.
I'm looking into the file upload on IOS6 and know that this is possible with the usual link:
<input type="file" accept="image/*" capture="camera">
Altho, the most tutorials and issues I can find are mostly about the upload function. In my case I need to be able to take a picture inside mobile safari with the build-in camera.
I have set up a page to test this (no code, only the link I posted above), and when I take a picture the app (camera app) crashes without actually saving my picture. Is this normal behaviour? Do I need to add some code to upload the picture first? Altho this last thing doesn't make sence to me, since you need to add an already saved picture to a file upload link.
Any help in this would be greatly appreciated :)
You should not need anything more in the code to avoid crash. It should work the same as choosing a picture from the library. I have tested this on an iPhone 4S with iOS7 and my Safari crashes too. It does not crash every time if I take a picture with the front facing camera (smaller picture?). It also works if I only load the picture from the photo library.
This is a bug in iOS I think. I managed to go around it by restarting my phone. Sadly there is not much we can do on the web side of things, except inform the user that the feature may be buggy.
Probably the best recommendation, until Apple provides a fix in a future update, would be to caution your user to close down the rest of their Safari tabs. (This lowers the memory usage and prevents Safari from crashing when doing the 'Take Photo' path through file upload).