I'm pretty new to programming and want some advice on the basic app structure so forgive me if this is pretty obvious.
The main part of the app is a series of 20 pairs of views which the users moves through sequentially (1a,1b,2a,2b,3a etc). Each a view and b view have the same layout as other a/b's but have different image, audio and text.
I could set out all 40 views in storyboard in one long line but that seems like I'm duplicating a lot of work (as well as creating a larger size app) although it would be conceptually very simple (and more stable?)
Alternatively I could just have two views (a and b) with all the content and some sort of counter so that Xcode would know which content to serve up depending on where the user is in the sequence. What would be the easiest way to implement this? I'm afraid however that this could also get unwieldy and perhaps keeping it simple really is the way to go.
Any advice gratefully received.
Many thanks
Design is totally dependent on complexity of screens not on the number of screen. If Screen won't have much variation then you can go for second approach having only 2 views and conditionally loading the data.
Alternatively if you want to go with approach first you won't need to duplicate all the steps. You can programatically create two super class which contains all the functionalities, and the part which varries for that you can create separate class(Inheritance concept). This will make the thing easier, you can reuse the code as well as increase the maintainability of app.
Related
I'm in the need of an Excel like grid in an attempt to convert an "application" written in Google Calc to a real application. I've got one implementation using Vaadin, but it (also) suffers from a long page construction. The screenshot below uses a CSS flex grid with individual divs, and given 6 weeks, there are over 5000 individual divs.
Constructing this page takes over 20 seconds, not something users will be happy about. I'm working on a version based on a table, but it does not seem to improve much. In the end the same amount of cells need to be constructed, whether they are DIVs or TDs does not seem to matter much.
Is there a way to construct such a grid in a more speedy way? I'm more than happy to solve "where did the user click?" on the server side. To be aware of: besides the number of cells themselves, each also has specific content, so just getting a grid shown is not enough.
Each component (div, or something else) is managed by the server. So when you have 5000 of them it's quite slow. You need to reduce the number of components managed by the server.
I can't give you a better answer since I don't know the requirements. But the idea is to try to combine some elements.
You have an example of a table generated ( instead of each element one by one) here: https://cookbook.vaadin.com/grid-details-table.
You can also create or own component. There is also a paid add-on: spreadsheet which seems to fit your needs. It's still in preview: https://vaadin.com/roadmap
The problem here is the complexity of the UI itself. Rendering 5000+ cells will be slow what ever method you use and what ever framework you use. There will be big amount of elements in the DOM and you need to load also lot of data upfront. And as you see the result is huge, and it wont fit most screens. So I would recommend further design of the UI. Is it really necessary to show all the weeks at once? Your UI's complexity will already reduce a lot if you show only one week at the time and add buttons to browse the weeks forwards and backwards. But even with that optimization you will have lot of columns. I would consider adding another browsing direction by day. Further knowledge of the actual purpose of the UI will naturally give more insight how to develop it further.
I am new to coding and wanted to get some hands on practice with a project I have in mind. Here it is:
Let's say you have blank page and on the side of a screen you have several items you can choose to draw on the blank page. For example the background can be mountains, the ocean, a forest etc. On top of that you can place a house, a church or another selectable element. Whatever you like.
It is like a picture editor where you can put together a picture with different pre-given elements. Or like in video games where you can create your own character.
What would I need to build a web application for that kind of thing?
This link should get you started but it won't be the complete answer to your question - http://www.webdesignerdepot.com/2013/08/how-to-use-html5s-drag-and-drop/
Essentially, you can achieve your image dragging and dropping using similar techniques. It will require a bit of Spike work from yourself, and looking into how HTML5 can handle drag and drop. I discovered this resource fairly quickly and I think the solution you want isn't as complicated as you may think, it just requires a bit of know-how regarding drag and drop operations within HTML5 :-)
Also, there may already be some JavaScript based API's that do this sort of thing easier but I'm not too aware - I suppose starting this way could be a great introduction for you and you may wish to expand once you've done some work for it :-)
Hope this helps you and your coding journey!
I'm analyzing my approach with Gmail's android developer's team approach in order to optimize drawing times and generally create more efficient apps.
My approach:
Below is the hierarchy inside a listview. It's quite straightforward. ExpandableListContentItem extends a Relative layout which has 3 Views:
Gmail app:
The following screenshot is how the listview in Gmail app works (SwipableListView). It's interesting to see that there is only one View (I guess aY extends ConvertationItemView) which in reality is quite more complicated than mine (I see 3 texts, 1 photo, 1 icon/button).
Question:
I would assume that this is a more lightweight approach to get rendered, is it so? Even if it takes me more time to code an optimal single customview per listview item it is worth the performance that it offers?
Finally the only way I know so far is to inflate an existing view inside another which is basically the first approach. I guess now my challenge would be to combine that relativeLayout with the 3 nested views into one. Is that correct?
PS:examples, open source code are welcome.
I would assume that this is a more lightweight approach to get rendered, is it so?
Yes it is. When you consider hierarchy, every parent measures their dimensions and passes it to child views from top to bottom. Reducing layers and having more flat view will save time.
Even if it takes me more time to code an optimal single customview per listview item it is worth the performance that it offers?
Depends on application you are developing. Depends on number of items in a list and how you get them. When you scroll through the list, if you think it is slow you might want to try that approach. I tried it on my previous applications and I could see the difference.
I guess now my challenge would be to combine that relativeLayout with the 3 nested views into one.
I don't know what you mean by combining them but the way Gmail does it that they have their Custom View. You can create your custom view.
Besides that, another thing to consider is overdraw. It is as important as having flat views. If you activate GPU Overdraw from developer tools and look at Gmail app row, you will see 0 overdraw. Make sure your code has no overdraw.
For further reading I would recommend you to check these blogs :
Performance Tuning On Android
Android Performance Case Study
Ours is an open-source Mac application localized by volunteers. These volunteers will do their work on special localization builds of the software (with unstripped nibs), then send us the changes to integrate into the original xib and strings files.
The problem is that, while there is a way to integrate string changes without blowing away previous size changes, I can't see a way to integrate new string and size changes (as when we add or replace views).
The only way to do both that I can see is for localizers to work directly with the original xibs and send us diffs. That means they have to download the entire source code, not just a localizable version of the release, work in Xcode as well as IB, and either run the diff command themselves (per xib) or install and use Mercurial.
Is there any better way for a xib-based application?
UPDATE January 2014: Apple’s ‘autolayout’ code combined with their ‘Base’ localization stuff took most my ideas and improved on them. I recommend against using my old tools that I talk about in this answer. But, also, man was I right!
I strongly strongly STRONGLY recommend against frame changes in localizations. I know this runs counter to Apple's advice, but there are SO MANY problems with allowing frame changes - you end up with a billion edge cases.
Imagine you have 10 XIBs in your app, and you support 12 languages. You've got 120 different layouts to support, now. You just can't do this.
Change the strings, leave the views where they are. Make 'em bigger in ALL languages, if you need to. It sounds like this shouldn't work but it does. (I won three Apple Design Awards with an app that's localized in 10 or so languages this way.)
Specifics:
For radio and checkboxes, just let them extend far to the right, beyond the last English character. That also provides a nice big landing area for imprecise mousers.
For buttons, they should be wide anyhow, because it never looks good to have text cramped in the middle of the buttons.
For titles on tableview columns, you should autosize when you load 'em up, if needed.
For explanatory text, you should have some extra space to the right, and maybe an extra line. It just makes the English version of the XIB seem less cluttered. Sure, the Germans are going to see a slightly tighter XIB, but, hey, they're Germans -- they're probably used to that. There's probably even a German word for it. "Deutscheninterfakkenclutterlongen."
If a text field is centered, just add equal space on both sides. There's no reason not to.
I've combined this with scripts that suck all the strings out of my XIBs and put them in .strings files, and then dynamically put the strings back at run-time, so anyone can localize my app without any special tools. Just drop in a bunch of .strings files and run it!
Blog post including full source: [Lost in Translations]¹.
I confess that I'm not all that familiar with the process of localizing Mac apps. But I did run across a script that's part of the Three20 iPhone library that seems like it might be useful: diffstrings.py is a Python script that "compares your primary locale with all your other locales to help you determine which new strings need to be translated. It outputs XML files which can be translated, and then merged back into your strings files."
EDIT: As a companion to Wil Shipley's answer to this question, I'll add a link to a blog post he just wrote that goes into more detail about localization, and provides some of the tools that he's built to ease the process.
Where I used to work, we had this issue as well. Our app was getting translated into 10 different languages.
At first, we tried doing what Wil suggested, which is to make everything super wide and fit in every language. Unfortunately, "online backup" might be pretty short in English, but in other languages (especially Spanish), it's really long ("copia de seguridad" just means "backup"). Widening our UI made everything look pretty terrible.
One day, I was playing around with some Core Animation stuff and discovered the CAConstraint class. CAConstraint is basically a way to define a layout relationship between two CALayers. You give one layer a name (like "layerA") and then say "layerB is constrained [in such-and-such a way] to a sibling layer called layerA". Then, whenever the layer named layerA is repositioned or resized, layerB automatically moves as well. It's really neat, and it's just what we were looking for.
After a couple of days of work, I came up with what is now CHLayoutManager. It's basically a re-make of CAConstraint and friends, but for NSViews. Here's a simple example of how it works:
CHLayoutConstraint * centerHorizontal = [CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMidX relativeTo:#"superview" attribute:CHLayoutConstraintAttributeMidX];
CHLayoutConstraint * centerVertical = [CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMidY relativeTo:#"superview" attribute:CHLayoutConstraintAttributeMidY];
[aView addConstraint:centerHorizontal];
[aView addConstraint:centerVertical];
This will keep aView centered in its superview, regardless of how the superview is resized. Here's another:
[button1 setLayoutName:#"button1"];
[button2 addConstraint:[CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMinX relativeTo:#"button1" attribute:CHLayoutConstraintAttributeMaxX]];
[button2 addConstraint:[CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMaxY relativeTo:#"button1" attribute:CHLayoutConstraintAttributeMaxY]];
[button2 addConstraint:[CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeWidth relativeTo:#"button1" attribute:CHLayoutConstraintAttributeWidth]];
This will keep button2 anchored to the right edge of button1, as well as keeping button2's Y position and width the same as button1's.
Internally, CHLayoutManager uses an NSValueTransformer to calculate the new positioning information. Some of the CHLayoutConstraint initializers accept an NSValueTransformer, so you can create arbitrarily complex layout manipulations.
We used this for constraining and laying out the entire UI, and then doing all of the localization in code (and subsequently calling -sizeToFit, with some modifications). Our UI would just flow into its final layout. It turned out to be extremely convenient. We'd just package up our .strings files, send them off to the translators, and then drop them in to place when we got them back, and our app would instantly be localized for that language.
CHLayoutManager isn't perfect. It doesn't resolve conflicts, but simply applies constraints in the order they're added. So you can constrain (for example) the MinX of a view 42 different ways, but only the last one will be used. Also, if you constrain the MinX and the MaxX, they'll also be applied in the order they're added and will not end up stretching or shrinking the width. In other words, constraining one attribute of a view will not affect the other attributes. It's compatible with 10.5+ (GC and non). However, due to some changes in Lion, it's unlikely that I'll address the shortcomings.
Despite these shortcomings, it's an extremely flexible framework, and (IMO) some pretty nifty code. (Plus, I swizzle -[NSView dealloc]! Yay!)
Update
Now that AppKit has this same functionality (via NSLayoutConstraint), I recommend using that system instead of CHLayoutManager. It is far more robust.
Bear in mind that XIB files are merely XML files in an obscure format, so you can translate those easily enough, provided that you can find what strings there are there to translate in the first place. For example, here's the snippet that creates a button called Jenson:
<object class="NSButtonCell" key="NSCell" id="41219959">
<int key="NSCellFlags">67239424</int>
<int key="NSCellFlags2">134217728</int>
<string key="NSContents">Jenson</string>
...
</object>
So you can get that string translated and then substitute occurrences of it in the XIB with your translated value. In order to verify it's working as expected, you could change the language to use random keys instead (like BUTTON_TITLE) which will make it easier to spot when one's missing.
However, the positions/sizes of the items are fixed, so you can have titles that overflow the space given in a different language. That's one of the reasons why Macs have separate XIB files for every language, to allow adjustments to be made on a language-by-language basis, however difficult it is to maintain.
I'm going to be going to be meeting with a number of programmers and custom software companies to get bids on creating a website for a company that I'm involved with. My question is this: What should I prepare for the programmers so that they can give me an accurate bid, timetable, etc. for the development of the website? I have a clear picture of how I would like the site to work and the features that I would like to have included.
I'd suggest using something like balsamiq to put some simple sketches together as suggested elsewhere.
Quite often the act of putting your requirements down on paper in a way that represents the actual site will flush out all manner of issues you hadn't considered before, and will give you a much clearer understanding of what you're after.
Also consider the sources of the data you're displaying. From a functional spec aspect, simply saying something like 'show this figure here' is easy. From a programming point of view, coming up with the figure in the first place is often the hard bit.
The best you can do is to put the end-user's hat on and describe what you'd like the system to look like / work.
Imagine all pages and create a new frame for each one. Make as many annotations as you can so all bidders know exactly what you are expecting.
I'd also add at the end if it's likely the site's requirements to change during development, so everybody's warned in advance.
Details Details Details.
You might think you have a clear picture, you don't. You need to write every single step down no matter how trivial. You will see there are things you haven't thought of.
Try to write down as much information as you can think of. Go through all the scenarios a user would when using your site. Use steps such as
1) User clicks on Buy Button
2) Screen shows up with 4 items, Link to details, price, quantity and a 32x32 thumbnail.
2a) If User clicks on thumbnail full resolution image i s displayed
etc etc.
Don't try to gloss over the "simple" stuff and you will get the most accurate bid possible!
Basically draw out what you want (ie textboxes, drop down lists, controls, etc) in very simple manner. Then add little numbers around each area that has some functionality. In the margins or on another sheet, describe each point you numbered on the controls with simple instructions on how that functionality should work.
Think of it as a skeleton to describe the application you want.
Not a complete list, but here a couple of thoughts:
Do not forget the back button.
Back button behaviour is an issue on every site I've ever worked on. Specify exactly what you want to happen on every page if the user gets to that page by hitting the back button. Often it's easy, but sometimes it is not at all trivial.
Security:
Do people need to log on, how, how do you create accounts, reset passwords etc. What pages need you to be logged on, what happens if you hit those pages without being logged on.
You could read Joel Spolsky's Painless Functional Specifications for ideas, but I've just tried to summarise what that means for web software too.
I usually do this in 3 stages:
a list of contents, under the headings they'll appear on the site. Get this firmly agreed by all parties before doing any wireframes;
a greyscale functional wireframe in plain HTML/CSS, using examples of real-world content and dummy static pages for dymanic content, with everything where it should be. This is the first thing programmers want to see;
a purely visual graphic mockup of each type of page - this is the next thing programmers like to see, as in 'show me how you want it to look and I'll make it happen'.