ng-be / 2016-app-ng-be-org Goto Github PK

The app should be updated with the current conference planning:

• put speakers in the datafile
• put rooms in the datafile
• backup datafile in the repository
• put planning in the datafile & link to the speakers and rooms
• upload datafile into firebase
• update todd motto description
• update the final hours

The speaker item for a list should be designed properly, not just using a basic list item.

Favoriting can be done on:

• the schedule page
• the session detail page

A user should only be able to favorite when he has logged in using one of the social providers

The manifest and other PWA resources are in the root of the application src.
When building the dist not all necessary files get copied to the distributable. The task is to hook into the ionic build process to make sure all those necessary files are in the dist before uploading it to firebase.

• hook into ionic build
• copy PWA specific files to the distributable ( browserconfig.xml , manifest.json, serviceworker, .. )

The session item for a list should be designed properly, not just using a basic list item.

Currently, the app doesn't load when offline

• Cache speakers
• Cache sessions
• Disable sign in/favorite/rate when offline

@jvandemo told us it didn't work for his iPhone. We should check this.

A user should be able to login using social providers and keep a state ( of for example his schedule / favorites & rating, tbd )

• login using facebook
• login using twitter
• login using google
• login using github
• login using email/password ( not preferred )
• the login component should be reusable for 'popup' authentication wherever needed

In an ideal scenario, we would want these users to be 'synchronized' when they login in subsequently using different social providers. For example:

1. I login with Facebook and make some favorites
2. I logout & later return to the application
3. Now I loggin with Google and I see the same favorites

I think this matching can only be done if the used emailadresses are the same:

• check if we can link users in-between social providers

The following visuals need to be updated:

• the inner logo
• the splashscreen
• the icons

codelyzer could enforce the Angular2 styleguide. Might be a nice addition to add that.

See ng-be/app-ng-be-org#4 (comment) for the context.

A logged in user should be able to build up a personal schedule using favorites.
As soon as a user favorites a session, it should appear in it's own timelime/schedule.

• when a user favorites, but is not logged in, popup a auth widget ( reuse the 'login' component ) and do the favorite
• do the favorite when logged in
• when already favorited, the session can be unfavorited
• list all the favorited session in his schedule
• provide an option to remove this session from his schedule
• ...

Ionic 2 can automatically render splash & icon images based on a template.
The generation for android is working, not for iOs:

• generate splash & icon for android
• generate splash & icon for ios

Rating can be done on:

• the session detail page
• double check that a user can only rate a session once.
• a user can choose to remove his rating if he wants to change it ( so to change a previous rating he has to remove it )
• set default rating to 5 (is 1 now)

A user should only be able to rate a session when he has logged in using one of the social providers

• Schedule Page (#54)
• Schedule filter page (#55)
• Schedule Details
• ...

Alright, this might be a little bit hard to explain, I'll do my best :).

So yesterday, I dived more into Ionic 2. I like how easy it is to get something good looking on the screen. What I dislike however is the structure. Pages are just components, nothing more nothing less. Why? Why aren't they modules that encapsulates everything from within that page. It could even encapsulate child pages... In my opinion, that would make much more sense.

Let's give you an example.

The schedule page has quite some html in the template file. Normally, you would work with dumb components to split everything apart. For instance, the session list is written like this.

    <ion-item-sliding *ngFor="let session of group.sessions" #slidingItem [attr.tag]="session.tags[0]"
                      [hidden]="session.hidden">

      <ion-item (click)="goToSessionDetail(session)">
        <h3>{{session.title}}</h3>
        <p>
          {{session.startDate.format('HH:mm')}} &mdash;
          {{session.endDate.format('HH:mm')}}:
          {{session.room.name}}
        </p>

        <ul class="tags">
          <li *ngFor="let tag of session.tags" [attr.tag]="tag" class="tag">
            {{tag}}
          </li>
        </ul>

        <ion-icon name="bookmark" item-right color="primary" *ngIf="!session.favorite && segment ==='all'"></ion-icon>
        <ion-icon name="bookmark" item-right color="secondary"
                  *ngIf="session.favorite && segment ==='all'"></ion-icon>

      </ion-item>

      <ion-item-options>
        <button ion-button color="favorite" (click)="toggleFavorite(slidingItem, session)" *ngIf="segment === 'all'">
          <span *ngIf="!session.favorite">Favorite session</span>
          <span *ngIf="session.favorite">Defavorite session</span>
        </button>
      </ion-item-options>

    </ion-item-sliding>

It would be much cleaner if we extracted the session item to a separate dumb component and work with a session input or something like that.

    <ion-item-sliding *ngFor="let session of group.sessions" #slidingItem [attr.tag]="session.tags[0]"
                      [hidden]="session.hidden">

      <session-item [session]="session"></session-item>

      <ion-item-options>
        <button ion-button color="favorite" (click)="toggleFavorite(slidingItem, session)" *ngIf="segment === 'all'">
          <span *ngIf="!session.favorite">Favorite session</span>
          <span *ngIf="session.favorite">Defavorite session</span>
        </button>
      </ion-item-options>

    </ion-item-sliding>

And embed the ion-item component inside the session-item.

With the current structure however, this would require us to actually bootstrap the SessionItemComponent at the root module of our application. Dirty!

Solution

1. Create a ScheduleModule which encapsulates everything inside the schedule page. You could add services, other components, pipes, etc without having to bootstrap them at the root for everyone.

import { SchedulePage } from './schedule';

@NgModule({
  declarations: [
    SchedulePage
  ],
  entryComponents: [
    SchedulePage
  ]
})
export class ScheduleModule { }

2. Create a index barrel file that exports the module and the page. We need the page so we can navigate to it.

export { ScheduleModule } from './schedule.module';
export { SchedulePage } from './schedule.page';

3. Import in the AppModule and remove SchedulePage from entryComponents.

That's basically it. In my opinion, a much better separation which allows you to easily create extra dumb components in order to keep your code clean. The ConnectionService can now be part of the ScheduleModule (if we don't need it somewhere else) and follows the Angular 2 way of thinking.

Let me know what you think.

http://ionicframework.com/docs/v2/api/navigation/DeepLinker/

I ran across this blogpost https://developers.google.com/web/updates/2016/10/navigator-share. It allows you to invoke the native share dialog on Android.

Might be to close to integrate now as we also have to subscribe for this feature to get a token. Let me know and I could have a look (or not).

ionic 2 rc 4 is out, we need to update

Steps to reproduce:

after first login we can favorite items
when logging out and loggin back in the favorites are only shown when favoriting or defavoriting an item.

• show info on first time visit to "add to home screen"
• keep a cookie/localstorage entry to make sure it doesn't pop up all the time!
• keep a link to this documentation page in the side menu

After a session has ended, a logged in user should be able to rate the session by providing a typical 'star score' and an optional textual review.

Requirements:

• the user should only be able to review a session once,
• the user should be logged in
• the user should be able to edit his review & save it

Todo:

• show the rating action in the session card when the session has ended
• open the rating action in a popup/actionsheet/whatever
• persist the rating in the database with the id of the user

Would it make sense if we hide the favorite button for let's say the continental breakfast?

If you press the login button on the sessions page, the tabbed pane at the bottom is still visible. If you press the login button in the navigation drawer, this is not the case.

Hey guys,

I was looking at your app and wanted to do some try-and-error refactoring and create a PR if I manage to refactor it.
However, It would be awesome if I could run the app using some kind of dummy data, afaik their is a call to addDemoSessions() comment out: https://github.com/ng-be/2016-app-ng-be-org/blob/master/src/services/conference-data.service.ts#L126

However, I do not see any way to uncomment this line as the method does not exist.

Do you have any firebase test account or something I can use to populate my own firebase ?

Ps: I know the readme says to open an issue before creating a PR. But I'm okay with the PR not getting merged if you dislike it or are already working on it . :)

Thanks !

ionic final was released recently, update the project!

The speaker item for a detail view should be designed properly showing:

all information about the speaker & link to his details
a link to his session
..

Update the share button en tweet button

• find new project credentials
• deploy using new credentials
• check functionality

Wouldn't it be nice if we used app.ng-be.be instead of the firebase URL?

The session item for a detail view should be designed properly showing:

• key information about the speaker & link to his details
• an explanation / description of the session
• ..