Is there disadvantages to using WebKit WebViews compared to using NSViews?
I'm using a webview to create a UI for an application. The application itself does not have much interactivity. I have seen it mentioned, on this website & others, that using a WebView can be convient means of prototyping.
However, with our team this seems like an ideal way to produce the production ready UIs, especially with WebKit. Are we missing something?
Thanks,
Ross
Okay, so you seem to be asking if using an HTML interface (presented via a WebView) for your application has any disadvantages.
The answer to this is "no", at least "not necessarily". This is analogous to building an iPhone specific web application, and there are some excellent examples of those. The caveat would be that a lot of those sites end up recreating the look and feel of a native iPhone app, for consistency and to make the users feel "at home".
Given that you're developing a native app anyway, it seems a shame to throw away, or recreate, the responsiveness and appearance of the native chrome. Of course, for certain types of applications (games are an obvious example) a user has no expectations about the application's UI, so you're free to knock yourself out.
The other factor to consider is the amount of interactivity (although I notice that you say there isn't much in your case). The native controls will make coding a lot simpler than having to capture all user input through the "filter" of a WebView, even though using one might make the initial layout of the screens easier.
I hope that's the sort of answer you were looking for (although it's mostly non technical).
As you might have known if you spend some time in the documentation, you'd have seem that WebView is a subclass of NSView.
The documentation says about WebView:
WebView is the core view class in the WebKit framework that manages interactions between the WebFrame and WebFrameView classes. To embed web content in your application, you just create a WebView object, attach it to a window, and send a loadRequest: message to its main frame.
And about NSView:
NSView is a class that defines the basic drawing, event-handling, and printing architecture of an application. You typically don’t interact with the NSView API directly; rather, your custom view classes inherit from NSView and override many of its methods, which are invoked automatically by the Application Kit. If you’re not creating a custom view class, there are few methods you need to use.
So here's the answer to your question:
Is there disadvantages to using WebKit WebViews compared to using NSViews?
Yes. You can't display any web content with NSView. That's what you need WebView for.
I suggest reading some more documentation though.
Related
Lately I have been playing around with the bluetooth framework and grew a strong enough knowledge to start building an application. The only problem is that all the examples I found and all the practice I have made consist in putting the core bluetooth core code inside the same file as the UIView with which the user is interacting.
I would like my future application to have multiple views in which the BLE scan occurs on the background. I initially thought about creating an object with a name similar to bleDeviceFinder and pass this object through each view. However, after thinking about it I realised that if I want something to happen in the current view I need the function didDiscoverPeripheral to have direct access to the UIView objects which it is supposed to affect.
I know it is probably a stupid question, what would be the best way to do so? I was thinking maybe to set and alert and subscribe every view to that alert; is this a good solution?
A quasi singleton BTLEManager that you pass around in the app. It sends NSNotifications for events like discovery, and your ViewControllers observe these notifications. The truth (i.e. list of discovered devices) stays in BTLEManager. Once a viewController has received such a notification it asks the BTLEManager for the list of current devices and then the viewController changes your views accordingly. The Views should never talk to the BTLEManager directly.
That's how I would do it.
I'm fairly new to Objective-C and cocoa programming, so I don't really understand the concept of App Delegates.
When we create a cocoa application, do we store our code (Methods, actions, outlets) in the App Delegate files or do we create a new file that will act as a controller and code from there. Right now, I put all of my code in those two files, but from what I read, your goal is to try to make your App Delegate files as slim as possible.
My question is: What's the usage of the app delegate files?
Talking about applicationDidFinishLaunching::
It's just your application entry point. Normally you only create the window and your first ViewController, or your Tabbar - your main starting interface class - here.
All the other delegate methods of the NSApplicationDelegate have other functions of course. Most of them are the point, where you react on the state of the app. Opened / Closed / Backgrounded / Reopened etc.
But you should probably have a look at the programming tutorials in the iPhone documentation. There is a lot of information on how to structure your objc projects. E.g. look here: Start Developing iOS Apps Today
Or if your looking for OSX Apps, look here:
1) Your First Mac App
2) Mac App Programming Guide
There is also a bunch of Sample code.
The App Delegate is a handler location to handle events that occur on the application. Things like open and close. It also hangs around the whole time the application is executing and you can grab the singleton instance at any point by doing [[NSApplication sharedApplication] delegate].
This comes in handy for handing objects between controllers and serving as a router for events. You can also store some data on the delegate if you need to modify/have access to it in different parts of the code.
This all works well for simple applications, but as things become more complex, you need to have some division of responsibilities. The AppDelegate should really only be responsible for actions that occur on the application itself, not on another view or a controller. Putting all/most of your code in the AppDeligate is certainly bad practice and will lead to horrible code as things get more complex and need to be maintained.
I have a general question for Xcode programming and the usage of the Xcode tools.
I am quite new (4 months) in iOS development and I almost never used the Interface Builder for my purposes. I always created instances programatically. My question is basically if you think i should get used to work with IB or should/can i proceed like i do now?
If you are fine with defining your UI programmatically, then I do not see any issues with that.
Interface Builder allows you to "graphically" define your interface, and this can be an invaluable tool for playing with your UI prototypes, but apart from that there is nothing that you can do in IB that you cannot do programmatically.
In my case, I see that it depends on the kind of UI that I design. When I need a pretty basic UI, the IB is unbeatable for me. On the other hand, when my UI tries to be a bit custom, then I prefer doing everything programmatically.
An interesting point is that you could use IB to design your UI, deciding on sizes and positions of your elements, and the create it programmatically.
Yes you should use IB, basically xcode having IB for ease of development, no need to setting controlls by using coordinates and each time see their visibility by running the app.
just drag and drop and at the time of making the views, you can see hows your screen going to look.
Also using IB is not a typical task so,start development using IB.
Here is a screenshot from Evernote. It appears to have (but i might be wrong) a custom UINavigationBar as well as a custom UITabBar.
A quick glance at the apps on my phone shows i could use a screenshot of Instagram, Path, DailyBooth, ...
From the docs:-
Because managing the navigation bar is
the responsibility of the navigation
controller, direct modification of the
navigation bar itself is considered
off limits for the most part.
Does Apple regard this kind of thing as grounds for AppStore refusal?
There's a distinction between "custom" navigation bars and using private methods.
Apple prevent you from directly modifying the navigation bar by make a lot of the required methods private or properties read-only. If you were to modify a read-only property or use a private undocumented method your application would be rejected (Apple automatically analyse code upon submission to detect for this sort of thing).
However, there's nothing to stop you from implementing your own UINavigationBar equivalent, or customising it using publicly available SDK methods. The issue then becomes whether your application strays too far from the Human Interface Guidelines: although to be honest, Apple are generally fairly flexible on that.
Whilst I wouldn't necessarily recommend this, I've worked on one app where we rolled our own navigation controller because we had some animation and transition requirements that we couldn't achieve with Apple's own class. As long as you're not calling anything untoward or drastically going against the HIGs, you're generally fine.
This is probably a simple problem for the high skilled Cocoa programmers, but I can't find how to control the graph in a separate window. I read carefully the Cocoa related books, go through many web notes,but I can't find a solution to my problem. The purpose is to use a dedicated window to draw the I=F(Vg) curves extracted by the GUI from a specific hardware. All the GUI and the hardware works fine ( thanks to the help provided by several members of stackoverflow) , but no way to send the parameters to the NSView to display the results.
So far, the GUI class is based on a NSObject, the graphic class is NSView.
Any idea, examples, links will be appreciated. Thank you so much.
Michael
So you have a controller class that receives data and owns a window? Just give it an outlet to the view.
This is the job of the controller in MVC: To pass data from the model (in this case, the hardware connection) to the views.