I'm developing a game for my dissertation, and I'm using the spiral method approach.
I'm having a bit of difficulty structuring my dissertation, specifically the design and implementation section.
My solution was designed as much as possible initially, and then after each prototype implementation, the design was refined and extended and prototyped again (this was repeated a few times).
My problem is how to structure this in my dissertation, my current idea is:
Design Chapter
Prototype 1 (Initial) Design
Prototype 2 Design
Prototype 3 Design
Implementation Chapter
Prototype 1 (Initial) Implementation
Prototype 2 Implementation
Prototype 3 Implementation
Any suggestions?
You might be better off switching the structure around to reflect the evolution of the software. Separating design and implementation does not make much sense as they are closely related.
Prototype 1
Design
Implementation
Prototype 2
...
I would go a step further and add a section on limitations for each prototype to explain why the next iteration was required. I consider putting the emphasis on what was learned during the prototype to be more important than the actual design and implementation.
Prototype 1
Motivation - explaining what the objectives are
Design
Implementation
Evaluation - looking back to the objectives and what was discovered
Prototype 2
Motivation ...
Related
I develop an app for online shop that should has some design features that I don't know how to implement. Lurking for it second day, but no profit. I suggest, that it should be the simple CV with some custom cells for different needs (banners, products).
Problem - design has scrollable horizontally content in each section and I see no simple way to implement it instead of writing custom flow layout.
I tried to make a tableView with collection view in its rows, but its not working correctly.
May be you know some examples of implementation of same thing in swift or a good way to make such feature without flow layout?
Refer mention link May be help you from this link:- https://ashfurrow.com/blog/putting-a-uicollectionview-in-a-uitableviewcell-in-swift/
I know this is a question that has been asked quite a bit, but it's iOS 9 and I still don't have a clear idea about what to do. For starters, here is what I seem to be surmising from all the data available:
Storyboards let you create segues. [I've never been a big fan of this answer because segues are often the least harrowing part of creating the UI layout for me.]
Xibs can let you create multiple top-level views. (Storyboards vs. the old XIB way) [I don't think I've ever used this much, though it seems rather helpful.]
Storyboards - Creating UITableViewCells is easier. [In my opinion, it's cleaner to create xibs for the cells and just invoke them in cellForRowAtIndexPath].
Storyboards can turn into one giant ultramassive file that is hard to edit. [I've seen this happen in practice and it is a big drawback, but at the same time...]
Storyboards let you arrange all your Views in one place with the layout shown as well. [This seems to be a big help for me. But then, over the years I've found doing this in code much easier. Which brings me to my final question.]
What is the performance aspect of both of these two things. My app is essentially the following :
A top level hierarchy of interconnected view controllers, not more than 5.
A large number of disparate, independent view controllers that range from Scroll Views to TableViews to static Imageviews.
Autolayout, size classes, the works.
For each of these view controllers, what is the performance of creating a storyboard for each of them vs. creating a xib for each of them. More importantly, what would be a good way to lay out an app like the one I've mentioned.
You definitely want to use storyboards for laying out view controllers - simply because you get access to topLayoutGuide and bottomLayoutGuide which the XIB editor won't give you.
For other views, it's a matter of preference. I tend to use XIBs for table view cells simply because I tend to reuse them on different screens and prefer to have them in their own files.
I would actually advise against manually writing view code where possible simply because it's much harder to read and work out how views are laid out, especially for developers who didn't write the code originally! For simple, dynamically sized things this can be fine, but if you're trying to lay out view controllers with different constraints depending on the size class it's going to end up a bit of a mess.
Yes, it's a pain to deal with merge conflicts of these files, but with iOS 9 you can split up view controllers into different storyboards a lot more easily using view controller references. Personally I find the inconvenience of merging storyboards/XIBs the lesser evil of having to write everything in code.
It sounds like a Storyboard is the right thing for your current project. However, my experience has been that Xibs and Storyboards are problematic in the real world, for these reasons:
extremely idiosyncratic from developer to developer, so it is tricky to build good storyboards as a team
black boxes, so they require a tremendous amount of knowledge to master (unbelievable amount of hidden behavior). Only the most superficial semantics are covered in the documentation.
internationalization is made much harder by being split up, especially if you have internationalized messages not contained in the Storyboard/Xib.
backwards compatibility breaks annually / deprecation guaranteed over time. This is especially difficult if you try to maintain compatibility with older devices.
As soon as more than two devs started touching our code we rewrote everything to avoid Storyboards and Xibs altogether, and we became much more productive.
If you have to deal with any of those real world situations, I heartily recommend programmatically creating all of your views. There is even an app that makes this easier (and is way more scalable). I have no relationship with this company or product, but it is hands down a better solution.
http://www.paintcodeapp.com/
Is what I'm trying to accomplish here even possible? I've been searching for hours for sample code and/or SO answers that demonstrate this simply enough to follow, but so far no luck.
Goal: implement something that looks roughly like this mock:
Yes, I know this is easy with a tableview, but the full design includes custom interactions, multiple columns, UIKit dynamics, and custom animations when adding/deleting cells, so UICollectionView is the better candidate. Until I can get this core layout to work, though, the rest of it is just a pipe dream.
So far I've started with a subclass of UICollectionViewCell that has a single label with constraints to all 4 sides of the content view. At which point I run into these issues:
It's unclear how I can calculate collectionViewContentSize() when the cells don't exist yet, esp. given that the majority of cells are actually offscreen most of the time!
If I just throw in an arbitrary content size (e.g., 320x1000), my views show up, but their heights don't adjust to the label content…I can't seem to read the cell height from within my UICollectionViewLayout subclass.
Seen or done anything like this? I'd include code, but after hours of futzing with it. I'm just looking for a clearer tutorial or sample code that fits this scenario.
There's a project you might want to look at. It's fairly involved and probably has a lot of code for situations that don't quite match yours, but does indeed create a chat view using a UICollectionView.
It can be found here:
https://github.com/jessesquires/JSQMessagesViewController
For item 1 - with regards to calculating collectionViewContentSize, I think you'll find you may not need to calculate that, at least as long as you're using a UICollectionViewFlowLayout subclass for the layout.
And for item 2 - rather than set a fixed 320x1000 take a look at the JSQMessagesCollectionViewFlowLayout.m for sizeItemAtIndexPath.
Sorry, this probably should have been a comment, but I lack the reputation to comment & so I made it an answer (doesn't that seem backwards? Ah well.)
I'm trying to develop a universal iOS app and ideally I'm trying to get as much code re-use as possible.
I'm using storyboards so the UI is segmented into scenes.
In the iPhone storyboard the particular scene in question is best suited to a table view.
In the iPad storyboard, the equivalent scene in the storyboard would ideally implement a UICollectionView and so render the content in a grid.
Both views should implement a pull-to-refresh control which in one case is going to call a [UITableView reloadData] and in the other a [UICollectionView reloadData].
Anybody any advice on how to get the maximum amount of code re-use, ie. what does the controller class look like?
1 option would be to have 1 monolithic class that conforms to both the UITableView protocols and the UICollectionView protocols but this doesn't feel right.
Another option would be to have a base class and then subclass it with specialisations for iPhone and iPad. Whilst this feels cleaner, I'm still thinking there might be a better way. In my first attempt at this it felt like there was more code in the specialisation classes than there was in the base class.
The third plan I've considered is simply to use a UICollectionView in both apps therefore eliminating the complexity of the controller. Hopefully I could force the layout of the collection view to be a grid on the iPad whilst tell it to mimic a table view on the iPhone.
Whilst on the face of it this sounds easy I'm struggling to make a UICollectionView work exactly like a table view would do normally.
Any advice guys?
Many thanks,
CA.
If you are not using some of the specific UITableView features[1], making UICollectionView look exactly like a table is trivial. I think I would go for using UICollectionView as it will allow more flexibility in the future and you will have to use it anyways.
When you are talking about code reuse you probably mean the DRY principle. It just says you should not write the same code or the same information twice, but I don't think this is your main issue here.
I would use a UITableViewController on the iPhone and a UICollectionViewController on the iPad. I think this is the cleanest and easiest way to go. What exactly do you hope to reuse among both controllers? The both require two different delegate protocols, so most of the methods will be specific to one platform. You will need two NSFetchedResultsController if you're using Core Data, but reusing the fetched results controller code only makes sense if you need the same data on both platforms.
If you create a new universal project in Xcode you will get a basic project setup that looks different on iPhone and iPad. Try to understand it (there are some details to pay attention to) before you start programming, I think it will answer at least some of your questions.
I am trying to write an iPad app with the basic purpose of form filling. I have 5 independent forms that I have designed in Interface Builder with each form having more than 50 UILabels and UITextFields along with a few Segmented controls in a UIScrollView (yes, its a really really long form). These forms need to be locally saved in the app itself which can later be emailed. After designing the forms I realised that creating IBOutlets for such a large number of different controls is going to be tedious and might also hamper the performance of the app. I am also worried about the complexity it will create in managing these outlets.
I am not sure if I have taken the right approach. Can anybody suggest me any alternatives. I am ready to start everything from scratch, all I need is a little guidance towards the right approach to solve this problem. I only need help with managing the input elements, the rest I can manage.
Any and all suggestions are welcome. Thank you very much.
There can be two kinds of UILabels and UITextFields.
1. Static/Fixed text inside.
2. Dynamic text.
You create outlets for dynamic values that changes at runtime. Or if you are implementing some thing from codes.
If you think 50 outlets are difficult to handle, you can create 5 separate controller classes for each forms, resulting in 10 outlets to handle in one controller class.