We are using NavigationView from touchkit Jar class from vaadin8. Now we need to upgrade our application to vaadin 24. So please suggest which Jar is supporting for Vaadin TouchKit
There’s no such thing, you’ll need to create a replacement yourself.
I would say that Hilla is actually the replacement. It is very different though, as with Hilla you will need to write views in TypeScript either using Lit or React.
When using Touchkit, the views were written in Java but compiled to JavaScript using GWT. Technically thus it is the same thing. In both cases your are writing logic that will run on Browser (fundamentally executed as JavaScript). Hence it was possible to use Browser LocalStorage for offline capability in Touchkit, and the same can be done with Hilla as well. (See: hilla-v2-demo/frontend/util/useOffline.tsx at master · TatuLund/hilla-v2-demo · GitHub )
It is also possible in Vaadin to create hybrid Flow / Hilla applications, where you have views defined both with Java using Flow, and mobile / offline optimized views with Hilla. So this is conceptually the same as having Vaadin 8 and Touchkit two servlets approach, where the other is the Touchkit.
So architecture and concept perspective this is the replacement, but requires total rewrite of the part of your application that now uses Touchkit.
But on the other hand if you do not use any offline capabilty now and use of Touchkit was merely due some mobile optimized widgets, then your need for replacement is obsolote as alll modern Vaadin components are mobile optimized and it is enough that you make your Flow app PWA and responsive.
I’m also still missing some of the old TouchKit components when developing apps targeted for handheld size. This is from one of my unfinished Vaadin 7 → 24 upgrades, might help you to get forward :
The VVerticalLayout is the Viritin version of Vertical layout.
@Tatu2 This question had nothing to do with offline mode of TouchKit and in general that feature was used by only a fraction of the users. Most of TouchKit code was never compiled into JavaScript or GWT.
(Vishal is a colleague of mine, so I think I can expand)
Of course we would like to migrate our touchkit-based app with as little change as possible, so if there was something that provided 1:1 functionality that would be ideal, however that ship has sailed. Frankly, it was not not nice of Vaadin to abandon touchkit with no migration path.
However, our touchkit app doesn’t have that much UI, so rewriting it won’t be too hard.
There is one part however that I don’t know how to do, and that is the sliding in/out on navigation. That was really nice. I’m sure it is doable with some css, but it is outside our expertise.
Just for context, here are a couple of screenshots:
Clicking on “4. floor” in the 1st screenshot and it would slide out to the left and be replaced by the 2nd screenshot. Clicking on the back-button “< Cabin/Bed” would slide it out to the right and be replaced by the 1st screenshot again.
This is not strictly a functional requirement, but made it really pleasing to work with.
The rest of the UI I’m sure we can do with standard Vaadin building blocks
I remember a chat a while a go I had with @Jouni1 about Navigation API - Web APIs | MDN as a really nice addition for flow ;) That would fix your problem
Edit: to be more concrete: NavigationTransition - Web APIs | MDN
Yeah, so you’d also need “NavigationManager” component as well. I have missed that as well in one app, but never did a counterpart for that.
The new browser APIs hinted by @knoobie would be great, but not supported in Safari(read iOS) is not good for many mobile apps.
I’m not particularly interested in browser navigation in this case. I don’t expect my users to use the browser back button. If they do and it works, then fine, but I’m also happy if the navigation is some page-internal state. In that case it is simple enough to do, except the animation, and that is not a functional requirement. I will miss it though.
The views in the StarPass demo app work like this, and we’re currently putting together the requirements for a layout component – “Parent-child layout” being the working title at the moment – that we’ll begin building in Q4.
Testing it with a mobile-sized window gave a very pleasing effect.
I like