We are evaluating CodenameOne to adopt it as our platform.
In the Showcase App, the menu buttons layout gets broken (button smaller than the image) after changing to some Themes like the "Leather".
Tested on Samsung A5.
Is it an application or platform problem? And can you fix it?
Problem screenshot:
(not enough reputation yet to post images)
The leather theme is a legacy from circa 2014. We don't maintain it because it's gone out of vogue with current flat design styling. We haven't updated the kitchen sink either for 3 years too, since we're more focused on apps such as build.
2014 predated iOS 7 which changed a lot of details about the treatment of the status bar. That means the theme needs to be updated but because it's so full of images it's a bit of a pain. We chose to leave it there with the quirks since it shows off the versatility rather nicely although it's pretty much out of date.
Related
Now that things are sort of getting stable, I am still doing the codename one todo app demo and got to the point where I added underlines under the label/checkbox. My git repo is
https://github.com/deanhiller/codenameOneExamples
****EDIT
I just published my build and ran on android phone and the basic todo app is not working either. I am not sure what's wrong, and if I can't fix this it may be time to jump ship and create two apps(one swift and one android studio...bleck ). I really like this concept and at 70/month, codeone was not a bad deal for what we need.
****END EDIT
If I click + 3 times though, the screen looks like this (settled on using intellij 2019.1.4 with codename 6.5.1 on MacOS Catalina 10.15.4). This is not what the demo should look like though.
and thanks at the amazing support Shai.
It seems you only defined the styles for the unselected theme. This means that when an entry is selected or pressed it's unstyled. You can see this by opening the theme in my repo and comparing it to your theme.
Since I wrote that book we've slowly moved to styling with CSS which isn't very different from the content of the book (slightly different syntax). That makes things like that easier since CSS implicitly defines all the 4 styles in the same way and changes things for a specific style explicitly. This is a bit more convenient. It's also easier to treat styling as code even though I'm not a fan of CSS.
The nice thing if you can "live edit" CSS which means changes instantly show in the simulator without interaction.
I'm a big fan of Zurb Foundation. They just released Zurb Foundation 4 which was redesigned to be mobile first. I'm fairly new to responsive design taking into account both mobile, tablet, and traditional desktop experiences. I'm trying to wrap my head around how best to manage my site's content for these different devices. With Zurb Foundation 4, you can hide or show content based on small, medium, or large device sizes. So, it seems with Zurb's approach you drop all of the content down to the device and let the CSS decide what content to show depending on device (this is responsive design).
My question is why do we have to drop all of the content to the device? That seems like a waste of processing on the server, a waste of bandwidth, a slower experience as the browser handles the content some of which may never be shown to the user because of the device they are using. Am I missing something? Wouldn't it be better to go back to the server and let it send content to the client that's appropriate for the device type? Shouldn't we be concerned about mobile user's data plans and not send down content that's not appropriate for their device type? All the examples that I've seen on responsive design has content for desktop and mobile/tablet downloaded to the client which seems to be a waste.
I'm developing a time entry application that has a different user experience based on the device type. Desktops (when in full screen) have a more detailed data entry experience whereas mobile/tablets have a different experience because of device real estate is smaller. I'm developing the app so when the desktop browser is resized to something smaller that 768px wide that jQuery makes a call to the server to swap out the UI for the "smaller" mobile/tablet version. Is this appropriate? I certainly do not want to download 2 versions of the app and hide one or the other depending on the device width.
Am I on the right track with my jQuery approach? Am I missing something regarding responsive design and needing to tailor the content to the device? Any ideas, suggestions, and guidance is appreciated. Thanks.
Mobile First with Zurb Foundation is basically a philosophy change by the Zurb team and if you want do develop a responsive site and not take a Mobile First approach then I suggest using Foundation 3 which is still available and fantastic. There is a book that I am reading that gives a great pitch for Mobile First, called Mobile First by Luke Wroblewski who is also listed as an adviser to Zurb.
here is an article by the same author that might be interesting:
http://www.netmagazine.com/interviews/luke-wroblewski-mobile-first
Basically: the premise is that you start your development and design for a mobile, meaning basically an iOS or Android style browser and then add features.
So instead of starting with a desktop / tablet experience and removing things as was commonly done with .hide classes in foundation 3 and could still be implemented in this way with foundation 4, they suggest using .show classes to add additional content.
This can be taken way further by using Compass and Sass Mixins. There isn't a lot of great documentation on how to do this, but you can basically keep your markup semantic, apply an id rather than a class and use the mixins to apply it to that id. There are advantages here in speed traversing the dom for an id vs. a class so it can be a good way to go.
Note: foundation 4 is using the drop in replacement (there are some limitations) for jQuery called Zepto. You can replace Zepto with jQuery if you really need it in foundation 4 or use foundation 3 instead. Zepto is much more lightweight and thus suited well for mobile.
As for it being faster by using jQuery to async load the data (I am assuming) based on the size of the browser, that is one way to do it. I am not sure if you are going to have a huge speed increase here. There are many strategies, pagination, async loading more data on the fly, and it depends on how you arrange the UX / UI around that data.
There are also many other issues such as caching resources, CDN, etc. that are typical in front end engineering that might give a faster load time. One resource you can check out related to this is ySlow.
There are also many design patterns such as off canvas slides, the 3 line (hamburger menu), loading more data on scroll, stateless apps, that can allow you to have the same functionality in a mobile app. If you go stateless, after the initial page load other pages should appear to be almost instantaneous.
I think the question here is more philosophical, in do you need all of the features, which is one thing that I believe taking a Mobile First approach is trying to approach.
Another thing to think about is the perceived loading time. I think I read about this is Seductive UX (another great read) but the faster you can get the page up with a loader or spinner, the faster it is perceived to be loading, even when in actuality it can be loading slower.
As a final note, if you plan on using foundation, you might look into using jQuery/Zepto with Modernizr to pull from the same media queries foundation is using. That way you don't duplicate or create something that is inconsistent with the rest of the responsiveness.
I'm developing the app so when the desktop browser is resized to something smaller that 768px wide that jQuery makes a call to the server to swap out the UI for the "smaller" mobile/tablet version. Is this appropriate?
It doesn't sound like a good approach do you take orientationChange in to account?
I certainly do not want to download 2 versions of the app and hide one or the other depending on the device width.
If you are on most tablets visiting the website in portrait and change to landscape you'll have to download the >768px UI after already downloading the <768px UI.
The mobile first approach in zb4 (with media queries) allow you to prevent stuff that belongs to big devices to be downloaded in to small devices. Basically you start with mobile styles and if the device meets the conditions you set on your mediaqueries (you can have much more breakpoints than the zf4 framework gives you by default) then the next rule jumps in.
I have worked in several 'responsive' projects even back in the pre-mediaqueries days were I use javascript to measure windowsize
Regarding javascript and like #powjames3 said zepto is much lighter / faster than jquery and if you could write your own javacript functions will be much better than using a over-bloated library.
Nowadays I do mobileFirst responsive webapps and websites use a mix of user agent sniffing ( sometimes to decide what image src or script / style src to deliver), despite the decision of the user agent tests i always serve mobile first mediaqueries, and conditionally loaded content.
"As Ethan Marcote (and John Allsopp before him), were right to point out, the inherent flexibility of the web is a feature, not a bug."
Here are some resources that might put you in the right track:
User agent parse and detection:http://mobiledetect.net/
Tutorial http://www.html5rocks.com/en/mobile/responsivedesign/ that covers:
Why we need to create mobile-first, responsive, adaptive experiences
How to structure HTML for an adaptive site in order to optimize performance and - prioritize flexibility
How to write CSS that defines shared styles first, builds up styles for larger screens with media queries, and uses relative units
How to write unobtrusive Javascript to conditionally load in content fragments, take advantage of touch events and geolocation
What we could do to further enhance our adaptive experience
Hope it helps
hopefully my questions won't be too vague.
I designed a pretty simple website. You can see an image of it >>> here
But now I'm trying to make a mobile version.
However I'm contemplating using a different html for the mobile version since the desktop version has jquery pop-ups (prettyPhoto) and a very large backround that scales, which aren't great on mobile screens.
I'm unsure of how to do that. My first question therefore is:
1.) How do I call a different html for mobile?
Also, for tablets, the website renders pretty well in landscape mode but becomes weird in portrait mode. So my second question is:
2.) Can this different html be called based on width? If so, any ideas how?
So if tablet is viewing website in portrait mode, they get the mobile version, if they are seeing it in landscape mode, they get the desktop version.
I am not sure what you are attempting to do, but from experience as both developer and mobile user, what you propose is not a good idea. Again, since you have not mentioned what you are attempting to do, I am speaking generally. Consistency is very important for UX, and delivering completely different behaviours and looks for orientation does not sound like a good usability. Also, remember that on today's tablets, switching orientations is very easy. Would you load each version on each orientation change? What if the user is on 3G?
But technically, it is possible to load depending on width or orientation. Use AJAX, and load the appropriate content.
In the past, I've created a "global" style sheet that all browsers and devices that support CSS should be able to receive.
The problem with that is that my old Nokia understood background image but the screen was so bad that the background images made the website look awful.
I then started putting any background images inside a CSS file with a media query so that old phones like this wouldn't understand it. However, this creates a lot more work. So I've started putting "global.css" behind a media query. The idea is that if the phone isn't capable of understanding media queries I don't want it to read my style sheet. Older (desktop) versions of IE are still served the CSS using conditional comments.
SO my question is, if a phone doesn't understand the CSS, would it provide its own fall back just like a desktop browser does? So at least a h1 is bigger than h2 etc and the text isn't all lumped in one huge block?
I'm guessing this could be a "It depends" answer but I'd appreciated feedback on this. I don't have my old nokia to hand so can't see what that is doing at the moment.
Many thanks
It does depend on lots of factors, such as vendor and how old the device is. However, in my experience generally they do render h1's bigger than normal text; can't say the same for h2's of further down the h's, though.
Usually for old mobile sites (back when XHTML-MP was the new thing and WML was all the rage) we used to set font sizes with CSS using these font-size values:
xx-small, x-small, small, medium, large, x-large and xx-large
From my experience, I can tell you that only small, medium and large work reliably across most feature phone mobile browsers.
All Nokia browsers (including the old XHTML MP versions) did include a default style sheet. This included basic styling for all the headers, a basic bullet and default bullet margins for lists and a bold and italic style. The various headers were not always that well differentiated but they was enough of a difference that one was discernable from another. The only real gotcha was with italicised text. There was often no italicised font per se so the browser would shift each character's pixels to the right to simulate a slanted font. This often resulted in poor legibility.
I have been planning since Summer to build a new hobby site over Christmas break in which I will use Silverlight to make some super-awesome navigation menu. I was crushed to read that Microsoft is de-emphasizing Silverlight (to throw all their weight into HTML 5 I guess).
I have never used Silverlight, but I am trying to build my development skills around Microsoft products, and Silverlight seems like a really cool technology, thus my interest. If it is not going to have Microsoft's full support I am a bit apprehensive about committing to it.
With that said I have some questions:
1.) At this point in time can I get roughly the same results from HTML 5 as I could Silverlight when creating my navigation menu and with roughly the same amount of effort?
2.) If HTML 5 cannot fill the shoes of Silverlight at this time then what (Flash)?
3.) Is my apprehension about Silverlight even justified (would you use it now)?
I would point you to these two posts:
http://timheuer.com/blog/archive/2010/11/01/silverlight-is-dead-long-live-silverlight.aspx
http://team.silverlight.net/announcement/pdc-and-silverlight/
In summary, Silverlight is not going away. Microsoft is recognizing the true cross-platform potential of HTML 5, but the spec for that isn't even complete yet, and we've got years before there is consistent support for it across the most popular browsers. Silverlight is the basis for development on Windows Phone 7, which is a bet-the-farm play for Microsoft.
Speaking for myself, I'm getting ready to develop an entire ERP in Silverlight.
This was simply unaltered tech journalism which may have focused a bit much on the face value, without further probing and questioning which was courtesy of Mary J Foley. Read the BobMu post.
Let me sum up the HTML5 vs Silverlight debate saying this...use Silverlight to build web apps, and HTML5 to build web sites.
Silverlight is moving forward just as it was pre-PDC. Ignore the hype, it is just that...hype.