I was looking for Backend Driven UI libraries for Android and came across Litho for Declarative UI. I was wondering if there is any helper/extension library for Litho that can generate the UI based on JSON.
Not smth we are aware of. But due to its declarative nature it's not hard to build one by yourself. Conceptually, you'll just need to propagate all props from json fields to Component props and a special field for a Component type.
Related
We are now in process of evaluating integration solutions and comparing Mule and Boomi.
Use case is to read an Excel file, map the columns to a pre-defined set of JSON attributes and then use the JSON to insert records into a database. The mapping may vary from one Excel template to another wherein the column names in an Excel may be different from others.
How do I inject mapping information (source vs target) from outside integration flow?
Note: In Mule, I'm able to do that using a mapping variable (value is JSON) that I inject using Mule DataWeave language.
Boomi's mapping component is static in terms of structure but more versatile solutions are certainly possible.
The data processor component opens up Groovy, JavaScript, and XSLT 3.0 as options. These are Turing-complete languages that can be used to bend Boomi to almost any outcome.
You could make the Boomi UI available to those who need to write the maps in JSON. It's a pretty simple interface to learn. By using a route component, there could be one "parent" process that governs the a process for each template/process and then a map for each template. Such a solution would be pretty easy to build and run; allowing the template-specific processes to be deployed independently of the "parent".
You could map to a generic columnar structure and then dynamically alter the target
columns by writing a SQL procedure that would alter the target columns.
I've come across attempts to do what you're describing (not using either Boomi or Mulesoft) which were tragic failures: https://www.zdnet.com/article/uk-rural-payments-agency-rpa-it-failure-and-gross-incompetence-screws-farmers/ I draw your attention to the NAO's points:
ensure the system specifications retain a realistic level of flexibility
and
bespoke software is costly to develop, needs to be thoroughly tested, and takes more time to implement
The general goal for such a requirement like yours is usually to make transformation/ETL available to "non-programmers" which denies the reality that there are many more skills to delivering an outcome than "programming".
This has been puzzling me for a while and I may be 'barking up the wrong tree'.
We currently use Sagemaker to make predictions on component failures for certain products in a basic way. This is done fairly simply by training the model and passing "modelcode, manufacture_date, component_code, failure_type" to the endpoint.
The issue is that certain products have trends in component failures and passing the above doesn't include the historic issues with a product in question. e.g. the product may have had 2 component failures that we would predict would lead to a 3rd component failure as other products have had the same issues/trend.
Ideally we would pass nested JSON into the endpoint as follows:
{
"modelcode": "XX001",
"manufacturedate": "2008.10.08",
"component_failures":[
{
"component_code":"CC001",
"failure_type":"shattered",
"failure_date":"2010.01.01",
}
{
"component_code":"CC012",
"failure_type":"cracked",
"failure_date":"2012.12.19",
}
]
}
Is this possible using AWS Sagemaker or would I have to use an alternative product?
Thanks.
Yes it is possible.
Sagemaker is very flexible, in that you can customize your own inference code to handle different types of input.
For example, if you are using MXNet as your deep learning framework, you can supply your own inference script and customize it to your own use-case in how to handle the input/output. For more information you can find the detailed explanation here: https://sagemaker.readthedocs.io/en/stable/using_mxnet.html#process-model-input
Similarly there is also one for Tensorflow deep learning framework.
An NSCollectionViewItem is derived from NSViewController. I use it as a prototype in an NSCollectionView. It has a property called RepresentedObject. Normally, I would use something like
var set = this.CreateBindingSet<DevViewController, DevViewModel> ();
set.Bind (devTextField).To (vm => vm.Text);
set.Bind (devTextView).To (vm => vm.BigText);
to bind UI elements with the vm. In the case of the NSCollectionViewItem, I want to bind to properties in the RepresentedObject. How do I do this?
NSCollectionView.Content takes NSObject[]. I'm currently taking my List and making an NSObject[] where each item in there is NSObject.FromObject(myClass) - which itself may not be the right approach.
Thanks in advance!
Update. It seems that if I can make my NSObject a KVO'd object ala http://cocoa-mono.org/archives/153/kvc-kvo-and-cocoa-bindings-oh-my-part-1/ that the bindings would automatically work.
The general approach of MvvmCross and its binding layer is that:
it tries to work with native controls,
but it also tries to encourage you to keep your ViewModel objects independent and unaware of any native choices.
So if you're trying to use a native control which requires you to supply a NSObject[] array, and you want to display (say) a list of customers, then a reasonable design choice within MvvmCross would be:
within the ViewModel:
to use a Customer object which provides INotifyPropertyChanged
to supply a List<Customer> as a parameter on your ViewModel
within the View:
to supply a NSObject[]
somewhere between the two
find:
a way of mapping your List<> to an []
and find a way of mapping your Customer to an NSObject
this can be found either:
using inheritance of the View and providing a custom C# property for binding
or using a custom binding
or using a value converter
The challenge of mapping the Customer to an NSObject is a particularly interesting one. If your end view is looking for KVO type functionality then I believe the conversion can be done by using a small Converter class which maps ValueForKey/SetValueForKey to their .Net reflection equivalent, and which maps INotifyPropertyChanged events to their DidChangeValue NSObject equivalent. I've not personally done this... but it feels like it should be doable, and (with a little caching of PropertyInfo objects) it should probably be reasonably efficient too.
Some final notes:
if you are marshalling a lot of calls between KVO and .Net reflection and this does impact your application's performance, then you may find using Rio style Field binding might be a faster experience, or you may find that it's faster to write hard-coded non-reflection based wrappers for your specific types.
if your ViewModel collection is mutable - e.g. it supports INotifyCollectionChanged then there may also be other interesting and reasonably efficient ways you can respond to the collection change events - although your view may not support these particularly 'beautifully' without some additional animation work.
I want a simple timeline component (like in video editing software) for a clojure/seesaw app and I am wondering if it is a good approach to implement this directly with clojure and seesaw or if I should write it in java and make my clojure wrapper around it.
Or more generally: is a functional programming language optimal for writing UI widgets? I cannot imagine doing that without a lot of state involved. And wasn't OO invented for UI-development in the first place?
You could go either way. On Overtone, we've built a number of custom graphical components directly in Clojure with Seesaw. Many times, an atom and (seesaw.core/canvas) is sufficient for this kind of thing.
Depending on how fancy you're going to get, one reason to do it in Clojure is you can extend Seesaw's protocols (selection, binding, etc) to the new widget so it works seamlessly with Seesaw. Another consideration is whether your widget needs to make use of Clojure data from other parts of the app. This will be much cleaner from Clojure than Java.
That said, if you're comfortable in Swing/Java, you can do it there and Seesaw will be perfectly happy to work with a custom widget built in Java. Good luck!
FP is good for doing UI programming but for that the underlying UI framework should also be based on FP concepts like FRP etc. In your case the underlying UI framework (Swing) is OO based and hence it would be more easy to implement it in Java but you can still do it in seesaw.
All else being equal (i.e. assuming you know both Clojure and Java), I would probably write this as a custom Swing component in Java.
Reasons:
Swing is fundamentally a Java-based OOP framework and is a better fit with Java in terms of paradigm
Mutable state is easier in Java than in Clojure
If you write it in Java, you can use it elsewhere more easily (e.g. as a library from other Java code)
It's easy to wrap a Swing component in Clojure after you have created it
Of course, for the application logic itself I would certainly prefer Clojure.
I want to use a tree in my Scala swing application, but the component isn't available in the API.
Does a wrapper of JTree exists ?
If not, do you have any advice for making it ?
Thanks
Even though you can use directly the Java JTree in your scala program, as illustrated by this thread, there is a debate about including a Scala wrapper of a JTree.
The following common usages are tedious, verbose, non-type safe, and/or require unsafe null usage:
Creating a custom tree model, backed by your own user objects -- the Scala
Swing way would be to have a standard typesafe Map behind it
Events - there are heaps of events created by trees -- TreeWillExpandListeners, TreeSelection, etc -- Using the Reactor/Publisher PartialFunction model would make this code far more readable and concise.
Editable components -- This is done with implicit values elsewhere in scala.swing, and should be here too.
Custom renderers -- Can't remember how Scala deals with these, but this is always fiddly in Java Swing too.
Bottom line is, JTrees are a massive pain to use in Java, for no particularly good reason. A Scala wrapper would be a massive boon for Scala Swing users.
A design is in progress, and a JTree wrapper proposal is available in this GitHub repo, made by kenbot (Ken Scambler).