Building a hybrid Meteor Cordova app: share experiences?

Since I really wish to use F7 in my next project, so I rushed to tidy up the sample project.

Changes are:

  1. Renamed the project, so repo git changed to: https://github.com/daveeel/meteor7 . @XTA, pls kindly update the link in your README, just in case someone else needs to follow.
  2. Use philippspo:momentum-flow-router instead the one suggested by @tomfreudenberg. Can’t figure out how mcissel:flow-transition works. :wink:

@waldgeist, sorry for the heavy use of .jade & .ls. Personally, I think it’s worthy to take some time to master Jade & Livescript. They are real time savers for we don’t need to keep track of unnecessary codes. That allows us to think at higher level. (Bonus: Livescript is FP at the core, while Coffeescript isn’t). Especially for F7, the DOM structure is so deeply nested, if you compare some of the .jade & .html sample, I think you’ll agree with me. Anyways, I’ll leave some of the .html & .js untouched for other’s reference.

No problem, everybody has his own preferences. I am convinced that things like Coffeescript and Livescript help a lot, but they also make it quite hard to interchange code. And you never know how long these languages are supported. So I tried to stay on standard’s grounds, though it is harder.

Regarding flow-transition: I also tried to make this work some days ago, but did not manage to do so either. If you should happen to make it work, please let me know :smile:

philippspo:momentum-flow-router config is a snap and it doesn’t mess with router definitions. But mcissel:flow-transition is the opposite, I scratched my head for sometime and didn’t even understand how to follow the doc … so I shall give it up for the moment.

Just committed with one more momentum-flow-router transition sample. See it from Home -> About and back with. Really easy.

Note that you do need to call myApp.init() for every template that serve as new route. Otherwise things won’t work as expected.

:slight_smile: Hahahaha … same as me yesterday … I will check this also again today and send in some infos if available.

In any case, thanks to share that stuff and knowledge

1 Like

You are welcome, without your help, I won’t be able get flow-router working.

Apart from smart-select issue, also found popover not displaying properly (dimmed together with the background) , with that many additions such as blaze rendering & transitioner wrappers, the component seems to be too deep inside the DOM comparing to F7’s official demo… any CSS expert to my rescue ? The test is at the home screen of my latest commit.

Did you add the popover at the correct position? It needs to be outside of the .views div (like in my repo @ android.html)

1 Like

That’s it! Thanks for the hint. Now committed with working popovers :smile:

+1 I had the very same experience.

1 Like

Nice work with the Framework7 integration @daveeel @XTA and others :smile:

We’ve come up with quite a different approach; we integrated F7 with iron router and used the CSS animations that it comes with to perform transitions with UI hooks. We’re simply using different controllers to determine whether pages are tabs, detail views, popups, etc. We’ve also got support an iOS-like history/back button.

We also called ours M7 :smile:

I’ll see if I can get something up on GitHub, there might be some cross-pollination possibilities. It’s quite tied-in to our project at the moment unfortunately, but I’ll see what I can do.

2 Likes

If you could, that would be excellent. I’m also working with F7 and Meteor but I chose iron:router so I’d be very interested in seeing how you got the transitions working and stuff!

FYI, I have a branch that reverts to iron:router : https://github.com/daveeel/meteor7/tree/iron-router
As far as I could find out, the behaviour of iron:router + ccorcos:transitioner combo is more predictable than the other flow-router combo.

If there’s no decent solution to flow-router + momentum combo, most probably I’ll go the iron:router route.

Yeah, I think we’ll have to wait until FlowRouter gets the love that Iron:Router got. Most of the available “router” plugins are still written for Iron:Router. That’s the reason why I’ve been not switched yet.

Hello, guys. I’m like you and I’m searching for a bullet-proof way to combine these two pieces of art - Framework7 and Meteor. I follow this discussion since several days and I tried daveeel’s work - both with iron and flow router. However it is far from production ready solution with lots of issues. Other solutions I saw so far also have issues. I can’t understand why we can’t use the router and css animations that come with F7? Maybe I miss something? They are perfectly tuned for the framework and we don’t have to reinvent the wheel. Why we can’t define all our pages in “template” tags and then load them to views with loadContent() method?

1 Like

I’m not qualified to answer your big question. :confused: Need someone who understand how Meteor internal works to answer that.

As far as transition works (though not F7 native) and we could add reactive data from Meteor, it’s good enough for my use case.

What are the major issues that you think are not production ready?

1 Like

Well, I think F7 router works with AJAX request, that will fail in case of Meteor. Maybe a working solution will be including all “views” in one single template, but then there is still the question how you would handle the reactivity, login, registration,… without writing too much code?

We use Meteor + F7 in our productional app without any major problems.

No, its not necessary to work with AJAX. Take a look at this: http://www.idangero.us/framework7/docs/pages-dynamic.html

Also, it can work with so called “cached DOM”, which is essentially all the DOM already populated in browser: http://www.idangero.us/framework7/docs/pages-inline.html#.VjnYfq4rJE4
Of course, the latter is not good for large apps.

So, basically my idea is to store all pages and other chunks in Blaze “template” tags. Then have links with “data-page” attribute and something like this (I’m just writing it to test the idea):

$$(document).on('click', 'a[data-page]', function (e) {
    var link = $$(e.target);
    if(!link.is('a[data-page]')){
      link = link.parents('a[data-page]');
    }
    var page = link.attr('data-page');
    mainView.router.load({content:$$('#'+page).html()});
  });

P.S. One of the issue of using a 3-rd party router is that you can’t have separate routing for multi-view apps. Or at least I don’t know how to make it without using F7 own router. Another issue is with browser back button (respectively Android back button).

Yeah, multi views could be a problem, but I mean I’ve read an article about Iron:Router and multiple views some time ago. Does F7 handle Android back button event in its core?

A general question slightly off-topic from the current discussion, but has anyone made an actual native android app that then uses Meteor on the server to deliver content and data? F7 + Meteor seems to be doing very well for me but I’m wondering if a native app may work better but have Meteor / Node handle all the server stuff.

I’ve just tried Meteor + NativeScript a few days ago (using Asteroid), but the ddp package throwed an exception. Maybe it has something to do with the missing WebSocket support in NativeScript, but I didn’t have enough time to figure it out.

I just want to give a little update. As I said above, using a third party router and third party load page functionality has some serious drawbacks. If you open the Framework7 source and look at how many things happen inside app.router._load() function, you will understand me. So, I went to a different direction - using nothing but the Framework7 own router and page load functionalities. For data reactivity I use React with the Meteor React package.
So, the idea is simple - on every link click I call:

view.router.load({
    content: '<div class="page with-subnavbar" data-page="' + page + '"></div>'
});

Then I have onPageInit event:

f7.onPageInit('*', function(page) {
      if(page){
        var myElement = React.createElement(page.name);
        ReactDOM.render(myElement, page.container);
      }
    });

So far so good. I’m still thinking for the best architectural structure that gives me the most flexibility.