Not really a fork...very confusing

[DaAwesomeP]

I was about to ask why all of the files beggining with . and those configuring other services like Travis are in a separate CodeBase folder since they destroy their purpose and will cease to work, but I realized that they were moved in a not-really-a-fork-manner.

• These two "repos" should at least be in separate branches if not completely separate repositories. It was very confusing to stumble upon too READMEs after seeing that the build command on the root folder's README failed. And, as I said before, Travis, Bower, and a proper NPM package are useless if a lot of those files aren't in the root. Combining projects messily in this way (instead of integrating them together as one, organized system as before) is a very bad practice. It leads to complicated build scripts to move around files and makes it hard to implement new features and fix bugs since so many files and so much build processing is involved.
• It's also very confusing to install NPM dependencies (which fails) and run the Grunt part of the build in one folder and then back out and run the full Cordova build in the root.
• Files relating to www are in the root www as well as the app folder in CodeBase as well as many assets in platforms/andoid that apply to all platforms.

_I would be more than happy to help clean it up_, but what is the structural goal of the app? I would assume that most of CodeBase would go into the root and the app folder in CodeBase would be merged with the www in root. I think that iOS testing should also start happening. I know that a true Tek Syndicate member propably wouldn't have one, but I have an iPod Touch and and I could set up an OSX VM to play with.

[jean1880]

Code layout

So, as an explanation, originally, it was it's own separate repo lol, but after backlash from rockking on the forum for making a seperate window, plus wendell's request to just have it exist in this repo, i took my original repo, and just put it into the fork.

• It isn't super well documented, since it has just been me working on it, however, I do have some automated scripts i have been using to handle the grunt build, which builds into the www/ folder, then does a cordova run command, which pushes right into my phone.
• As for the build process, I am using two separate tools to build the app:
  • For the main app, in CodeBase/ I am using yeoman, with the main angular yeoman generator, found here
  • Then the main cordova/phonegap generator to actually take the app and compile it into the native APK, it is, admittedly, a hack and smash method, as I haven't found a single full, generator, that does both, in a completely neat fasion (if you know of one, would love to know)

Overall Goals

Stage 1

First and foremost, I wanted to make an app, that would enable full forum interactivity, aka posting, creating topics, etc, making use of modern tools, that would greatly improve the speed and functionality of the forum, but also enable native capabilities for push notifications when people respond to topics etc, without having to wait for an email notification.

Stage 2

Secondly, making use of youtube's API, I wanted to have the videos populate inside of the app,and allow the users to browse the various Tek sub channels, AKA TekEnterprise, TekLinux, and search the videos for specific topics.

IOS testing

Although yes, apple products certainly are not pervasive in the community lol :p, i did plan on adding support. Making use of phonegap will make cross platform building super easy, the only catch, currrently, is in the way the server handles login. Since the server makes use of cookies to register a user as logged in, it has posed some unique difficulties in the app. Since phonegap is a browser, sitting in a native window, specifically android (have no apple devices to test), the app had some quirky behaviour when receiving the cookies. According to some digging, and verified through my tests, when the app receives a cookie return, the native window intercepts and sets the cookies, and does not pass them on to the browser. I forked an old cookie interface here that cleared cookies, and added the ability to return said cookies to the native window, and as a side project plan on adding the ability to set them as well (I hate cookies, but since the phonegap plugin repo did not have such a plugin thought, hey, what the hell, why not), as such, I have only currently added that ability to the android code, and planned on adding IOS once I got a bit further with other functionality in the main app.

Help

Any help, or suggestions are more than welcome, it sounds like you have plenty of experience with Node/NPM and cordova, I have been going through and documenting most of my code, but can certainly add more details, and am currently cleaning up the nav bar, in response to issues with the tablet build. Beyond that, if you have any questions, fire away!

[jean1880]

On a side note, if you want to start contributing, just shoot wendell a request on the forum for git access, I do not have access to add a contributor

[DaAwesomeP]

I can just send in pull quests from my fork for the time being. You can merge them that way.

[jean1880]

Sure, we can do that as well, I still need to implement, native push notifications, and a settings page. The settings need to be able to allow a user to turn off push notifications, if they so choose, plus anything else relevant we can think of. Many of the nav links are dummies atm. I can make a full issue list if you want to start tackling tasks.

[jean1880]

Do you have a trello account?

[DaAwesomeP]

Why not just stick to GitHub? You can assign issues to people and set milestones and labels.

[DaAwesomeP]

I think that we should tackle the structure problem first so that any future contributors won't have to spend a while figuring out how it works first.

Here's how I think the structure should work to prevent confusion:

• src
  • www will hold the non-platform-specific code; will be merged with the current www and CodeBase/app
  • platforms
  • android, ios, blackberry10, wp8, etc.
    • www will hold the platform-specific sources; nonbuild items such as icon can stay in the root platform/<platform>
• www will be where the build scripts build to (for non-platform-specific code)
• platforms
  • android, ios, blackberry10, wp8, etc.
  • www will be where the build scripts build to (for platform-specific code)
• test
• plugins
• res
• hooks will conatin scripts that simply call YeoMan or Grunt
• all of the files for NPM, Bower, Travis, etc.

Does this look good to you? I'm going fix this before I actually delve into the app itself.

[jean1880]

Trello allows me to make checklists, and clear tracking on the project, I am fine with git if you are, and if you can edit the config files to work off of that sure, the app/ folder though is non-minified, where as the www/ folder is a built, minified folder, with all of the bower scripts, and custom files minified and to only a few files. I just am not familiar enough with all of the config files to tweak it that much. In short, yes lol, if you can make that work, then that would be great, let me push my current version up though, before you split it off, so those changes get tracked with it

[jean1880]

Then we can use gitflow for future changes

[DaAwesomeP]

:+1:

[wendelltron]

Things are looking good so far on the last build. I should be able to help with the stuff.

I don't mind to reorganize/rebase to take the "old" versions out. We should keep an eye on some of the old version stuff because the json/views part of it can still pull data from the main site. E.g. stories, videos, etc. that are linked there.

We are close to rolling out a new design on the main site but the json views should mostly keep working as-is. The v1.0 app could read/deal with those. So we can re-use some of that easily here.

Does it matter about that this will essentially be 'almost' cross platform out of the box? I have a full ios suite of test devices and emulation platform.

Thanks for working on this you guys, we really appreciate it.

[jean1880]

Well, if the main API changes, just let us know what is happening, currently, the only requests I am making to that bit, is for login, was going to go right to youtube for the videos etc. Cross platform wasn't super high on my priority list, but felt it was necessary to provide at least android and iOS support, even if only a small percentage of the community uses iOS, my perfectionist attitude won't let me just leave it alone lol. Currently, as stated above, iOS is dead, until i can deal with phonegap, and it's native cookie management, but do plan on finishing that as I get some more functionality closer to done (iOS is on backburner)

[wendelltron]

my internal team has a good deal of phonegap experience, so we can probably help out with ios if no other voulnteers help. So that part is handled. I hope the login stuff won't change at all. Or the json feeds. Just the site's visual theme. Public dev site should ne up.. soon.

[jean1880]

Okay, awesome, I am currently looking to see if I can use Swift in phonegap for the ios plugin component, as my Objective C experience is zilch, and was not looking forward to tackling that beast. My repo for that is https://github.com/jean1880/Phonegap-Cookies-Plugin, so if anyone wants to look at improving on what I have, that would be awesome, was just a quick one night hammer out for me. Beyond that, if @DaAwesomeP can rebuild the config files, to clean up the build process, it might smooth out my work, and make it less of a cluster bomb of builds, making it easier for others to hope in and deal with extending it. I will also work on expanding my own code documentation, to ensure that it is very clear to anyone hoping in what is doing what.

[DaAwesomeP]

@jean1880 Have you tried using localStorage? I'm not sure how well performance is with it compared to cookies, but I've used it before.

@wendelltron I'm not worried that it "works" the first time we try to build for iOS, but I am worried that there will be code spilled everywhere that will make getting to the point of building a nightmare. If the code is all in the android section only, then there will be problems.

[jean1880]

So, building is already cross platform friendly, that is handled by phonegap, not sure what you mean by spilling out everywhere, maybe just not understanding your thought process on that, and yes, for my own app, I am using localstorage, I only needed the cookies for handling the CSRF requests, which want a cookies in the request, and in dealing with the login cookies i get when you log into the forum. I actually cache the first ten posts to localstorage, on the main page when you load the app, to speed up app load times for the user when they open the app, rather than making them wait, especially since the first three posts, which take up most of the screen, are often stagnant, and do not change.

[DaAwesomeP]

@jean1880 I mean having lots of code in the android-only section that may not need to be there. That will make it a nightmare to move to other platforms, as now it has to be ported over. The only need for platform specific code that I see now is the cookie problem.

UPDATE: I just realized that what I am seeing is just the built code, not any platform-specific sources. I'll be sure to add a proper .gitignore with the new structure.

[jean1880]

@DaAwesomeP Ah, I see, well, so far, there isn't anything android specific, I am trying to avoid special use cases like that, and it should be fine for that the whole way through.The cookie issue I had, and created the plugin for, should have the same issue on iOS, just haven't been able to test. I agree that we should avoid specific builds like that, and by sticking with phonegap, that shouldn't be a problem

I also can't foresee any platform specific resources either, as we are not dealing with anything that isn't available on basically every platform out there (push notifications, and cookies being the only native code snippets that I can foresee using, at this time)

[DaAwesomeP]

I've got it all restructured and working (from a Grunt and PhoneGap standpoint) and will push it soon.

However, I'm getting an error when running in the browser (and probably in the simulator too since it shows the same page): Template for directive 'navMobile' must have exactly one root element. I thought that minifying the templates could be affecting this, but I get it again when running without the full build (unminified). I checked app/views/navMobile.html, and there is definitely only one root element. @jean1880 unless you know what the problem is I might report the bug elsewhere.

[jean1880]

That is a known issue of my current updated modular nav stash. It has to do with the templates I am using in the angular directives. Also found a few other issues when I was playing with it today, just was waiting on rebuild of the code layout to start pushing through much changes. So, on that note, if that is the error you are getting, it is the last build state of the app in the master branch. 👌 Once that gets pushed through, I was going to throw the old nav in, and branch out for the nav fix until I get it done before bringing it back to master.

[DaAwesomeP]

I think that we should use a more reliable navigation system (i.e. a more widespread library). This will save time, energy, and bug fixing. One like this will do the trick (look at the "push" and "reveal" examples here). We're already using Bootstrap anyways. We can simply have multiple buttons that open different drawers.

[jean1880]

The nav system I am using supports that by default, I chose not to use that specific feature due to navigation speed. It is up for debate though. My rebuild will make management easier for both UHD tablets, and lower resolution a bit easier. The library I am using is twitter-bootstrap, as it was rapid to prototype, and get a clean theme, without having to build from scratch. My complaint originally with a single pop out menu was that it adds extra clicks to the user to navigate. Modern design tends to want to avoid extra workload for the user when it isn't necessary, and i agree, it is a bit of a pain to have to open the menu, then select my option, and sub option, or be presented with a massive list of options that can be an overload of information to the user. So that is my case for using the multiple dropdowns, as opposed to a single massive dropdown/slideout. I think we could check with the community, and get feedback to what they would like, as either case is as easily maintained, if built right.

[DaAwesomeP]

I didn't realize that you were using the built in Boostrap navbar system. I'm still getting familiar with the code. However, I don't know where the more clicks are that you're talking about. I'm not saying that we combine the chat, search, and main menus, but rather use a different menu system. The example one above slides out (looks cleaner), is scrollable (for smaller screens), and can show more information (bigger width and more clean). Look at the YouTube app, for example. It's menu shows profile information and a plathera of options. This is great for small screens that won't be able to fir more than what is currently in the navbar. My cheapo phone has a 400px x 800px display.

[jean1880]

Ah, okay, that is true, yes, looking at what you sent, it is just an add on for bootstrap, I can add it to the nav system, and it would help with those really low resolution devices, plus, might help with the tablets, as it looks like his can be forced to render as a push menu in any view size. I'll add it to my task list for the nav rebuild I am doind, and see if i can use it to limit the nav back to one system. The problem I had was that bootstrap's navbar on UHD devices started rendering as a desktop view, and totally destroyed what I was going for, that then needed two menus to handle, hated it, felt dirty, so that might help. If you want to go ahead and make a pull request if you are comfortable with the strcture you rebuilt, i can merge that in.

[DaAwesomeP]

I'm writing the build instructions into the README. I will push as soon as I can.

[jean1880]

Alright, sounds good,

[DaAwesomeP]

Added pull #15. Discussion should continue there.