I want Bixby to access the inner features of the application. Like to compose a message and send it in a Chat App. Is there a way to do so?
Sure, you can! As long as the application has REST (Or SOAP) endpoints that can be invoked, it can be called from Bixby.
Having said that, Bixby has many built-in features that allows developers to create rich, natural conversational experiences. As a general guide, the data intensive and complex computations parts of your capsule should be run on an external REST endpoint while the conversational experience (and the associated logic) should be driven from within Bixby. Hope this helps.
I am in the process of migrating applications from desktop to web. To migrate I need to reverse engineer to get functional requirements using the case. The application to be migrated does not have documentation. Can I make use cases based on menus on the application? example of the use case of the farmacy menu or the use case menu laboratory
Not really. Or at least you should not try it that way. Use cases are about the added value a system delivers to its actors. You can guess it partially from the menus. But only partially. The only thing you can get from the GUI is some kind of wire framing for classes representing the V in MVC. That's already way beyond use cases.
I'd been using RestKit for the last two years, but recently I've started thinking about transition from these monolith framework as it seems to be really overkill.
Here's my pros for moving forward:
There is big need in using NSURLSession for background fetches and RestKit has only experimental branch for transition to AFNetworking 2.0. No actual dates when transition will be finished. (Main Reason)
No need for CoreData support in network library as no need for fully functional offline data storage.
Having headache with new concept of response/request descriptors as they don't support different parameters in path patterns (ex. access token parameter) and there is no way to create object request operation in one line with custom descriptor. Here I am loosing features of object manager as facade.
I. The biggest loss of RestKit for me in object mapping process.
Could you recommend standalone libraries that you use which shows themselves as flexible and stable?
II. And as I sad I need no fully functional storage but I still need some caching support in some places.
I've heard that NSURLCache has become useful in last OS release.
Did you use it and what's the strategy?
Does it return cached API responses when network connection is down?
III. Does anybody faces the same problems?
What solutions have you applied?
Maybe someone could give some piece of advice about architecture that he or she uses in multiple apps with pure AFNetworking?
I. In agreement with others who have commented, AFNetworking + Mantle is a simple and effective way to interact with a Restful API and to replace RestKit's object mapping process that you miss.
II. To answer the requirements of your caching support is highly dependent on the context. However, I have found for my recent functional requirements that caching a view model for a particular controller's screen and only caching reference data returned by APIs allows me to keep the application logic relatively simple whilst giving the user some continuity. A simple error notification for connectivity issues can be dealt with a cross-cutting manner.
III. One thought on the architecture relevant to this aspect is to ensure that the APIs the app is dependent on provides data according to the app experience. This allows your app to focus on what it is good at (a very slick user-experience) and moves logic into the API's closer to API dependencies such as data. This has a further benefit of reducing the chattiness of the app.
I am using ZK Framework right now in one of my application. ZK Framework supports MVC as well as MVVM design pattern. Now for a new project I would like to use JSF. Does JSF support the both the design patterns or only MVC?
No, MVVM design pattern not supported by jsf only MVC support.It is used only desktop application.JSF also know as MVC fremework.
From http://blog.oio.de/2011/12/05/jsf-and-mvvm/:
The first M in MVVM stands for Model, and it is the very same model that we use in our MVC approach. In fact MVVM does not replace MVC, I rather prefer to see it as an additon to MVC, so there is nothing new here.
The first V in MVVM stands for View and again, there is nothing new to this part. It is the component that takes care of the client side representation. So there wont be any notable change to our views since we will continue to define them using Facelets.
VM in MVVM stands for the ViewModel, our client side model. The ViewModel is bound to the Model but it is exisitent only on the client side, though you are free to sync it whenever needed with the Model on the server side. But, more important is, that you can do whatever you want on the client side without having to send callbacks to the server.
First of all we need a next-generation-JSF-implementation, which supports the MVVM concept. The ViewModel would be created by this yet to come JSF implementation before a requested view is delivered to the client. Our ViewModel will be created from one or more JSF Managed Beans that form the Model. I can think of a nice set of class- and field-level annotations to tell JSF what parts of our model should make up the ViewModel on the client side. Once the view is delivered to the client, the ViewModel will be manipulated by client side scripts upon the form is submitted. Then, in the following iteration of the request processing lifecycle, JSF has to deal with resynchronization between ViewModel and Model. Admittedly, this might be the most tricky part, but I’m confident that the Next-Gen JSF Impl will manage to do that ;-)
From Understanding JSF as a MVC framework:
The nodes M, V and C are a maximum connected graph, meaning each part can communicate with every other part. E.g. if the model changes, it can push this change to the view. This is particularly visible in case there are multiple representations of the view in a desktop application. Change one, and see the other update in real-time.
Due to the client/server and request/response nature of web applications, classic MVC doesn't map 1:1 to most web frameworks.
More information find this link: http://www.tutorialspoint.com/jsf/jsf_architecture.htm
I disagree with user2860053's answer because it makes unnecessary assumptions about MVVM. MVVM is not about client and server responsibilities. The blog post cited only argues that a specific web application scenario involving a combination of client-side MVVM (as implementend by knockout.js) with server-side MVVM doesn't work well with JSF. It doesn't say anything about server-side MVVM.
In my understanding (which IMO corresponds to the original definition that is also referred to by the ZK documentation), the core ideas of MVVM are:
a) to keep a distinction between the UI's concrete structure, controls and layout (i.e. the view) and its state and behaviour (i.e. the viewmodel), and
b) link these using a two-way data binding.
Figuratively speaking, starting from "MVC", part a) adds the "VM", and part b) removes the "C" so we yield "MVVM":
In MVC, the controller is written for a specific view class/interface, and it's the controller's responsibility to read user input from the view, convert it and write it to the model, and to invoke business logic according to the user's action.
In contrast, MVVM doesn't have any controllers that are tightly coupled with view or model. Instead, there is a generic mechanism which uses declarative two-way data bindings for filling the view with data and converting user input and feeding it to the model, and for binding controls to business code (or presentation-only actions from the viewmodel).
So how does this apply to JSF?
In JSF, you don't write a controller for every Facelets page you write, but let the JSF lifecycle do the work of filling model elements with data from submitted forms and invoking methods according to the user's actions according to EL bindings, so the second property b) always holds for JSF.
As for the first property a), it's up to the programmer to implement high-level view state and behaviour in separate classes.
JSF puts more focus on creating components for view state and behaviour.
Viewmodels are made specifically for one kind of view, and model the whole abstract state and behaviour of the view, so I think that even "light-weight" composite components are too generic to take the role of a viewmodel. But there is nothing to prevent the developer from creating his own classes for this, i.e. write one's own viewmodel classes and bind them in the EL context.
In conclusion, JSF is not made specifically for MVVM, but contains mechanisms that can be used for implementing (server-side) MVVM.
I have a mixed UI (Win App, WPF App, and soon an ASP.NET MVC App) setup, so far I'm using Client Application Services for security. I know how to programmatically get a user authenticated and doing so is working beautifully. However...
I want to implement some cross cutting that basically checks to see if the user is authenticated all the time. Since everything will be accessing web services I want to enable this as a standard execution for pretty much everything the UI does. So far I'm thinking the PIAB - Policy Injection Application Block - will serve that function. What I'm wondering is two things;
1 Will the PIAB cover that needed functionality? Verifying authentication at every practical step if used against the UI?
...and...
2 Are there alternatives out there besides the PIAB? I'm curious to do a comparison of aspect oriented policy injection frameworks.
I'm not really familiar with Client Application Services but from my experience, most AOP frameworks wrap interfaces in order to implement the cross-cutting functionality. If CAS uses interfaces, you could probably just wrap them with what ever functionality you require.
Alternative AOP frameworks:
Spring.NET
Castle Dynamic Proxy
Spring.NET and Dynamic proxy seem to work in much the same way and have much the same performance in my Hello World type tests (about half-way between direct calls and invoking through reflection). PIAB is significantly slower than both these frameworks and I found bit more verbose. It does have the ability to be configurable via xml and I'm not sure if that's a good thing or not. Not sure if the other frameworks provide that. It does of course have the MS stamp of approval though :P.