IDE: Eclipse
Desktop OS: Mac
Device : Android 4.0.4
Hi,
last week i sent a new android build to the server, and it updated the jar files i have on my Mac, then i installed the app on LG android 4.0.4 device that i tested before, and was surprised to find some pages display all black.
After investigating a little, i discovered that when i use tabs on any form the form will be displayed black only on android, no problem on simulator nor IOS iPhone 6S.
I looked at the forum and i found similar problem happened a year ago , and the solution was to use "android.asyncPaint=false" temporarily . now this removed the black, but messed all the rendering while navigating between tabs.
So my question is why this happened now? the past three months i was developing and deploying on android without any problem. Did the newest update corrupt something?
Thanks
Sam
Using the android.asyncPaint flag is discouraged as it will fallback into a relatively slow compatibility mode. We are currently investigating some regressions in some rendering optimizations that affect some devices and are in the process of deploying a solution for that.
Please let us know if the issues persist.
Related
I have copied the project from my old amchine to windows 10 machine. Application works without any problem on simulator. If I right click to see the properties, I don't see IOS, Android and build hints. Please advise if there is something I'm missing here.
This was removed ages ago in Codename One 5.0 but was deprecated before that. See https://www.codenameone.com/blog/removing-old-preferences.html
You should use Codename One Settings in the right click menu.
I have a strange problem I need some help with.
Very recently I started experiencing a problem with the hamburger/side menu.
On startup our production version renders the hamburger menu in black but the current dev version renders in blue.
Once I login on the dev version, and start using the app, when I go into one of our application's forms, the hamburger menu disappears. The side menu can be activated by a slide-in motion.
I first started seeing this when doing a cloud/device build, not on the simulator.
A day or so after I got this on the simulator.
Thinking it may have been an environment issue (specifically I had been doing some theming with the GUI designer), I set everything up on my Windows VM, with a clean copy of the production code copied out of SVN - but I get this problem on the 'clean' version.
As I inherited this code, I was able to go back to the machine left by the previous developer and in running their version in the simulator all was fine. Black hamburger on login screen and present on our application forms.
I submitted the code to do a SAAS device build but then a library update ran on this previous developers machine, and I now get blue Hamburger at startup and missing on our application forms in the simulator - the same problem that I got.
Seems to point to something in the new libs. So, I then pegged the versioned build back a level (3.6 rather than latest) - to try to resolve any 'new version' issues but I get the same problem.
I guess we are missing some initialisation steps out on the new sidemenu - our code has been in place for a few years now, so ideally I would like to build against the previous version of the CN1 libs where we didn't have this problem until I have time to work what we are missing.
I thought versioned build would give me this ability but the problem persists- any assistance would be gratefully accepted.
UBUNTU 16.04
Windows 8&10
Eclipse Oxygen
We transitioned to the on-top menu over the weekend. This has been announced a while back and despite that as usual people were caught a bit off guard. We posted multiple updates on that to the blog so you should probably keep an eye on that.
The on-top side menu uses the default TitleCommand UIID styling where the old side menu had a different UIID but I'm guessing the engineer in charge used the theme constant sideMenuImage which we didn't include in the first release of on top side menu. This should be fixed in the update coming out this Friday (November 3rd 2017).
FYI You can disable the on-top mode using Toolbar.setOnTopSideMenu(false) although I would recommend sticking with it as it's WAY better.
I am using https://github.com/brodysoft/Cordova-SQLitePlugin for my cordova based app and it supports android, iOS, windows OS for now.
However, we have also added blackberry OS to the app and I believe this sqlite plugin is unsupported for blackberry. As of now, the index page gets loaded in blackberry simulator and it stops there since the db does not get a call.
I am stuck at this since 3 days now and haven't found a solution yet. Could someone please provide with a solution as we only need to get over this step to publish the app successfully?
I was building an app in xcode 4.6 (ios6.1) and everything was fine.
I ran the same code through xcode 5 (ios 7) on an ios7 device and simulator, and I ran into the full screen (status bar included) issue, horizontal scrollview issues, modal viewcontroller issues, et al.
I’m using a navigation controller with the bar turned off. Instead I’m using a custom view to pass for a bar. So the extendedEdge thing isn’t working as well.
I understand that eventually, I’ll have to update my design and implementation accordingly.
Now here’s the dilemma – I ran the app (backed up original code) from xcode 4.6 (ios6) on an ios 7 device, and it’s working absolutely fine. It’s leaving it’s gap for the status bar, and there are no issues at all.
What I can’t understand now is how to proceed?
Will the app be accepted if I continue working on xcode 4.6 with ios6 (since it’s almost finished)?
I’m not able to move to xcode 5, since it has only the latest ios7 as the Base SDK.
I can’t find a legitimate way to add ios 6 sdk to xcode 5 (except copying the 6.1 SDK to the xcode5 package).
And, if I hadn’t downloaded xcode 5 DP (which installs it separately), the mac app store would have updated my xcode 4.6 to xcode 5
Apple still accept applications submit through Xcode 4.6
But consider that you would loose some new functionality like having different icons to each OS version etc.
Moreover, your app won't use the 64-bit processor (it is still compatible but if your app is a game or something like that it is recommended to use it).
I assume that in few months you won't be able to submit apps using the old Xcode.
UPDATE:
For you to be able to use status bar as before (like hidden), in your apps plist file add a row call it "View controller-based status bar appearance" and set it to NO
Just to update people who might be looking for an answer to this -
Apple will only accept apps and updates made with Xcode 5 on iOS 7, effective 1st Feb 2014.
So I have a website and I mean to make 2 version of it, the desktop version (with full features) and mobile version (simplification of the desktop version). I'm using media query in CSS to adjust the style. It works well in native browser. When I open my web using native browser it will show the mobile version style. But somehow when I open my web using Opera Mini, it keeps showing the desktop version instead.
I have googled it and didn't found any clue. Any idea how does it happen?
Thanks!
I finally found what's wrong with it. Turns out I was stupidly using #media screen only and Opera Mini doesn't seem handle it well. I've googled it for hours. Someone said actually Opera Mini supports #media screen but other people said that the right media property for Opera Mini is #media handheld. Well, I tried to play safe by simply changing it to #media all. And it works!
There are a number of reasons why Opera Mini is showing the desktop version of the site. The most likely is that your website is not properly detecting Opera Mini as a mobile site and is not returning the correct content. If you're using some plugin or other piece of software that is automatically handling the routing of desktop vs. mobile for you, that might be the culprit. Also, it's possible that this is happening by design, because of how Opera Mini works.
Opera Mini runs web content through Opera's own proxy servers and attempts to 'optimize' the content before delivering it to the user. That is, content is rendered first on the proxy server and then delivered to the device. This of course creates all kinds of complications for someone who is trying to deliver a consistent mobile web experience to their users. Fortunately, Opera provides a development guide to help give you a better sense of what's going on and how to cope with it.
Opera Mini is, in my experience, a very difficult browser to work with. At the Wikimedia Foundation, we server a very limited Wikipedia (and sibling project) experience when we detect someone's using Opera Mini.
You should definitely read through the opera mini development guide and make sure that any device detection you're doing is correctly recognizing opera mini as a mobile browser. If you're just using media queries, you may either want to reconsider a more robust approach to mobile detection, or adjust your design accordingly to work for opera mini. Good luck!