new to codename one, and I'm looking to build a fairly robust app. I've read a lot of codename one documentation and have looked through many of the demos on git. My question is, what is the best way to architect the application?
Here are my basic requirements:
Splash screen
Lock screen (enabled/disabled by user)
Sliding (hamburger) menu
Contents of sliding menu will change based on current 'form'
Application settings
Based on this short list of requirements, would it better to make each different screen a form, and the sliding menu for each a different 'instance', or make a main form that contains the sliding menu (and just change contents of menu based on current screen) and make each different screen a component instead of a form?
Also, I was considering coding it by hand, and not using the gui builder.
Thank you.
Greg
I would go with separate forms mostly because of the hassle of updating the side menu for every selection you make. This would also make the general design more flexible.
Related
I would like to be able to add a menu to a desktop application that I have started to develop. I mean a classic application menu, which on Windows is displayed immediately below the title bar (with items like "File", "Edit", "View", etc.), while on MacOS it is displayed in the top bar common to all applications ("App menu"). Ideally each menu item could invoke an ActionListener, just like tapping a Button.
However, I have not found any information about this and I do not even know if it is possible at the moment. Thank you for your suggestions.
This is a feature we plan to add early on in the 8.0 release cycle as we already make some (minimal) use of it in our own apps. Right now the only option is to use the Swing APIs to add the menus using native interfaces.
You can get all the JFrame instances (of which there can be only one) and add any menu to that. If you use the Mac JMenuBar on a typical Codename One build then it will be on top by default since we set this implicitly through: System.setProperty("apple.laf.useScreenMenuBar", "true");.
You can just add entries to menu bar.
Well ... at the risk of sounding like I really don't know anything about programming, I have a question about controls in Silverlight 5.
I have an OOB App that I am working with, but I need to add the User Menus (File, Edit, etc.) that are normally seen at the top of all apps. There used to be a control in VS (the Menu control) that was easily configurable. What is the control used to create the User Menus in Silverlight 5? The Context Menu is not what I am asking about. That is the right mouse click menu ... so that's not the answer ...
Please, understand my problem. It's been since Silverlight 2 since I worked in Silverlight. I appreciate any information you kind folks would be willing to provide.
There is no such thing available directly from Microsoft (meaning it's neither built-in or present in the Silverlight Toolkit).
You will have to use third-party controls such as DevExpress or Telerik.
EDIT: Some more advice in response to your comment.
Another possibility is to create UIs from scratch. There are two forms of UIs that I found inspiring lately, both of which don't use any ribbons or drop-down menues at all. The first is to use "Windows 8"-like dashboards instead of traditional menues, the other is the Windows Azure Management Portal (a web application).
I don't use traditional UI frameworks for menues myself, but mostly because I don't like those approaches and I'm picky with how user interfaces should work and look like.
But obviously you have to make a serious time investment to go new ways. And it will heavily depend on your application what approach makes sense.
Here's one simple approach that could work in a number of cases, I used it for a database application (I call it the Windows-Phone-7/8 approach):
The screen is divided into the "page" area and information bars. The information bars contain no menues, just who's logged on, a back-button, a home-button, and context-sensitive buttons depending on what's in the view. So basically it behaves like a web browser and you navigate through the app by clicking on "links" (buttons that take you elsewhere).
There's only one page area, so no windows and no popups. I've gone to the extreme of making even dialog windows to be pages.
Now you need menues. You do that with "dashboards", ie. pages that present some overview stuff and buttons that lead to the other areas of your application.
Although you could have action buttons like save or delete on the page itself, I put them in the bottom bar (but they are still dependent on the page your on) - that is exactly how it works in Windows Phone 7/8.
One last advice: The real effort is usually not in the menus anyway. Beside your application logic itself, it's a lot of little things like login screen, error handling and how to present error messages (look at the windows azure management portal for how they did that really nicely) and gracefully failing on session timeout. There's also a lot of nuisance on how you manage your data (ria-services, etc.).
So as long as you don't need fancy data grid grouping, rich-text edit or excel-like pivot controls, a toolkit might not help you as much as you'd hope - because they give you only the controls, not the entire UI.
I'm trying to build an app in winforms with something similiar to masterpages in asp.net - a menu on top and when choosing an option from the menu the entire screen on the bottom will change while the menu remains (there are 10-15 screens in the future app, some are quite similar, some are not).
What is the best way of doing this? Should I use different forms for each screen or use a panel or something else?
If I use a panel or something how do I manage to use the designer with so many panels taking space on the screen?
Try with the MDIParent Form's. View the Example
http://www.codeproject.com/Articles/12514/Multi-Document-Interface-MDI-tab-page-browsing-wit
If it is just keeping the same menu and opening/closing parts of the UI you could simply add and remove instances of usercontrols to the main form.
If you need more features such as docking (like Visual Studio) look at this
Another option is to use Form inheritance
Which one to select depends on what you want to reuse and the features you need.
One option would be to make your application an MDI window and then load entire forms, maximized, into the parent window.
Then, you would be able to treat each form as its own self-contained item, since it really would be exactly that.
Is it not an option for you to use WPF? A WPF browser application fits the paradigm you are describing quite well.
I am working on a little WinForm app and have been trying to find the answers to a few questions i have without any luck. Im a ASP.NET developer so WinForms development is new to me.
Here is my main question:
How do I create a menu system that once selected the contents will render in the Main form of the selected item. If its a GridView I want to the GridView to render inside the main application so they can navigate away without having to deal with the modal popup. I do not want to popup forms unless i explicitly say so. I guess the equivalent to this would be using a Master page in ASP.NET.
Make sense?
The closest thing to Master pages in winforms would be MDI (multiple document interface), which is a hideous Windows 3.1-era abortion of a user interface. Why this option is even still around, and why anyone still uses it, is beyond me.
The second closest thing (and something more acceptable as a UI) is just to have one main form in your application, and implement the different pieces of functionality your app requires as separate user controls which are displayed on the form and hidden as the context requires.
A weirder method, but one that might also work for you, is to use forms inheritance - design one "master" form with the menus and controls that you want to always be present, and then have each form in your app inherit from that master form. This would not appear to the user to be much different from my second option above, so I wouldn't bother with it.
There really isn't anything similar to Master pages in WinForms.
The closest to what you want to use would be a TabControl selecting a different tab will display that tab over the other tabs. If you don't like the tab look you could extend the TabControl to not show the tabs or hack it together by placing the TabControl inside a panel just large enough to show the content but not the Tabs and change tabs programatically in your menu control.
I have a winforms application that doesn't have a shared set of tools that I can provide on a toolbar. But I want to have a toolbar, so I was planning on using that space to provide quick links to the most popular portions of the product. I will eventually add knowledge to the product to know which screens the current user favors and provide those as quick links on the toolbar. But is this a reasonable use of a toolbar for a desktop product, from a design and usability point of view?
Do not automatically add knowledge about what a user prefers to generate a toolbar. Having a dynamically generated toolbar is confusing for users. It's fine if your configuration bar makes suggestions dynamically (i.e. suggesting buttons), but changing the layout itself is evil.
I think a toolbar makes a good aesthetic, but if you merely want to seperate parts of the app then a Tab bar makes more sense for usability.
With the advent of tabbed browsing, every user understands the tab concept.
Sure. Firefox has something similar in their 'Bookmarks Toolbar'.
Peachtree Accounting also has a toolbar like this, as do many others.
Tabbing is OK as long as there aren't too many.
Would be real good if the user could personalize the toolbar themselves. Sometimes I don't only want places I frequent, but screens that I use occasionally that are hard to find through menus or whatnot.
To me, this looks like a job for a menu with a MRU list, or support 'Add to Favorites'.