Assume you have to develop an app, which needs a completely customized user interface so that you can not use any standard UI objects in Xcode.
How would you proceed to create such an user interface? Would you use the interface builder? Would you create something like a master parent UIView? What are the best practices to achieve this?
What would be the most elegant solution with less code duplication?
If by "complete customization" you mean the look and feel of the app,
then I suggest to design the IB objects you require using some design IDE's such as photoshop and then use those slices for your project.
This is the best option I find so far to get a complete customized look with minimal code, and by minimal, I mean you don't actually require any coding. You can do this complete customization within your Interface builder.
However, I don't think you can completely ignore standard UI objects as you require them to add basic functionality.
If customized controls are what you are looking for, then I suggest you to create separate custom control classes so that they can be reused anywhere in your project, or in other projects too.
Here are two wonderful tutorials on custom controls:
http://www.raywenderlich.com/36288/how-to-make-a-custom-control
http://www.raywenderlich.com/56885/custom-control-for-ios-tutorial-a-reusable-knob
Hope this helps!
Related
I would like to know if it was possible to perform dependency injection for native platforms accessibility features, as Automation Properties is not good enough.
By this, I mean that I would like to add hints/descriptions and other native accessibility features to my Xamarin. Forms view items such as entries or labels. If it isn't possible or this is a silly way of doing it, is there another way to apply native accessibility?
Pointing me in the right direction or a small example would be very helpful :D Thank you
I have created a webapp using Wix, which relies heavily on the repeater element to display content from a database inside a repeating element. Repeaters do pretty much exactly what I want, but I realize they are built on a pretty sophisticated API, and there's a lot of stuff making this happen in the background.
Ultimately for this project, a native iOS app is the end goal. However, I have no experience in xcode - but willing to learn. Before I get in too deep, is there any kind of functionality I could find to achieve something like this?
Thanks in advance
You can't convert Wix Repeater element to Xcode. But, you can make deep customization to your Wix elements by using Wix Corvid.
If you not familiar with it, it's is a developing platform integrated into the Wix ecosystem that allows users to build advanced sites. Among other things, it’s able to create and manage databases, build dynamic pages, host user-generated content and more.
For a mid sized application that makes use of MEF catalogs is there really any advantage in my using Prism modules rather than just putting the different functionality into different class libraries. I just can't see why I would need to use Modules.
Anyone have any thoughts on this?
Thanks,
Richard
Modules are used when you want to perform initialization actions when the module is loaded. This can be for example the registration of views to regions using the Prism IRegionManager interface.
Whater PVitt Saying is correct plus i would like to add to it.
Modules are always a good option for the scalability.
you can easily do future enhancements by having Regions,each region having some view associated with it and each view in different module.
when i say each view in different module it means you should find out which view is having some other view related to it and make a clubed view of these two views and have single module for these views. after all its your call.
for e.g.consider your application has a menu.Toolbar for each menu item is same i.e. having same functionality then you can have ToolbarView+Menuview inside "MenuView".MenuModule will have this final MenuView.
So my opion is go with modular approach if you have any future enhancement or if your project is going to change time to time like new functionalities on user demand etc.
Modules are a wonderful way to allow multiple development teams to develop at the same time. Also assist your to organize and maintain the Single Responsibility principle of SOLID principles in a Project level.
It helps your to have separation of concerns.
I want to separate concerns here. Create and embed all the UI logic for the Custom XML designer, object model, validations etc in to a separate assembly. Then the Package framework should only register the designer information and ask for a UI Service and everything works magically.
This way I don't need to play with the Package framework (Visual Studio Package) assembly, when I need to modify the UI designer.
This question also applies to anything where you have to separate the UI logic from the Skeleton framework that loads it up, like a plugin.
I have several choices a ServiceProvider model, a plugin model or may be other.
Any samples, suggestions for patterns, links are welcome.
Update 1: What I am looking for is a thought such as - "Does Prism (Composite WPF) fit the bill? Has anyone worked on a project/application which does the separation of concerns just like I mentioned above? etc"
(I am still looking out for answers)
I've created a VSPackage that loads an editor. The Editor sits in a separate assembly and implements an interface that I defined. The VSPackage works with the interface, so any changes I make to the editor (and its assembly) does not affect the VSPackage as long as I don't change the interface.
What you're asking about seams very much like the separation of concerns that the MVC pattern tries to enforce.
ASP.NET MVC is already out there with a preview 5.
It's mainly for web but I think they are planning on using it also for WinForms, but I'm not sure.
I prefer the Model View Presenter pattern
Someone on here recently recommended BWToolkit, and it really impressed me, so I started googling for more IB plug-ins. I've found a couple on random blogs, but haven't been able to find any kind of repository/aggregator for them. Anyone know where I can find more of these?
Thanks.
I just created a page on CocoaDev to list them [edit: question originally just said “Interface Builder plug-ins”, did not mention Cocoa frameworks], with the two I know of listed.
Well that's a good start. I guess that wiki page is the de-facto repository, for now. Seems like there's not much out there.
You are not looking for Interface Builder plug-ins. You think you are, but you aren't. BWToolkit, the example you use in your question, is not an Inteface Builder plug-in. Brandon bills it as an Interface Builder plug-in but it is actually a framework and a plug-in. The framework contains the actual controls. The plug-in contains the integration with Interface Builder.
So really, what you are looking for are frameworks that contain or provide Interface Builder plug-ins. I have changed your question to reflect that, so it is more likely to be found by people using Google to search for similar things in the future.
I know what I am looking for. Not all frameworks contain IB plugins. I am looking for a specific subset of frameworks, those which contain IB plugins. An IB-plugin without a framework is useless, therefore the framework part is assumed. I am NOT looking for regular old frameworks, so stop trying to change my question to that. Your additions only seem to be confusing people.
I have reported your post, hopefully moderators will be able to stop your obnoxious behavior.
"Without a framework, what would you have to plug in to IB?"
Your words, not mine. Anyways, I'm done arguing this with you. Just remember that I can roll back for every time that you edit.
It's clear you have a lot of experience in this field, but instead of offering answers you decided to nitpick where there are no nits to pick.
Additionally, you have not "changed the question to refelct that," you have changed the question to a completely different question. I would have though that after four rollbacks you would relaize that you're doing more harm than good. Just stop, okay?
Of course, Chris Hanson is absolutely correct when he says that an Interface Builder plugin is useless without an accompanying framework. Interface Builder merely provides a graphical way to manage objects in a framework; without the framework itself, Interface Builder has nothing to manage.
However, I do think that there is a completely valid sort of Interface Builder plugin that wouldn't necessitate the installation of an accompanying framework, and that would be one that provides Interface Builder integration features for objects in Cocoa/Cocoa Touch which would otherwise appear as just generic objects.
For those of you who come to this page Google, please recognise the difference between Interface Builder plugins and frameworks: even the examples mentioned above work on frameworks (they could be Foundation, AppKit, UIKIt, etc.)