CoreSuite acts as a layer between Microsoft 365 and an enterprises IT admins

CoreView

Start a Premium Content Business Using Node.js, React and Cosmic JS Extensions

This is the story all about how I built (with the incalculable help of ) a React/Redux Grid Component, appropriately (and boringly named) . taco React-Redux-Grid This is about how we started building a thing, how it changed along the way, the things we messed up, the things we learned, the things we’d do differently, and the things we’re going to do going forward. Starting to Build a Thing At the time, I was working for an organization that was revamping their UI stack from Ext JS to a more modern platform based on . Without going into too much back story, our existing app was a monolith with dozens of views, hundreds of rich UI components, and a bunch of spaghetti holding together our concept of (more on this later). In short, we had a bunch to rebuild (exciting!), refactor (hard!), and reimagine. One of the big obstacles for us was that we needed a robust grid component since much of our application was built around displaying and interacting with tabular data. Although we did our research, we couldn’t find an extensible enough grid that suited our UI and data needs. I will also admit that we had a penchant for creating things early on, since our previous applications heavily involved extending EXT’s components rather than building our own, and we were feeling bitten by that mantra. React state management Very early, we knew we were going to commit to React. The community was behind it, it fit our functional tastes, and the API was clean and expressive. We got a little lucky in choosing , though we toyed with and , finally choosing Redux because the single-store metaphor made sense to us. Redux Flux Nuclear I didn’t stop to think why our UI Components needed to be via Redux. Now, of course, I fully understand the convenience of having component state accessible via the `store`. It’s pretty cumbersome having to jump through hoops, retrieving React state from the component instance. But honestly I don’t think I thought about that at the time. I think I just wanted a Redux Component because it was an interesting problem. connected Anyways, here’s the short list of high-level requirements we came up with prior to building: * Handle large data sets* Open-ended event model, where DOM interactions can correspond to certain callbacks* Each row needs to be able to trigger dynamic menus and actions* Support a flat list or tree structure* Resizable/Orderable columns* Custom rendering models for cells* Editable rows, validation, persistence* Tested. Fully tested.* Fast. Real fast.* Extensible/Modular Style Although we ran into a bunch of problems immediately, I’m only going to touch on the most interesting ones: The `DOM` Problem Now we all know that React renders things as a tree — which is great. Well it’s usually great. Take a look at this grid. What do we notice? We have a header and some rows. Simple right? Well, yes, and no. The problem here is that we have a scrollable container with a bunch of rows, and a disparate header that should be in sync with all of these rows. What’s the big deal you say? Well let’s look at the hypothetical DOM structure this presents: <table><thead> …headers </thead><div style=”overflow-y:auto”><tbody><tr></tr>…more rows</tbody></div></table> I’m sure you’ve guessed by now that this just isn’t going to work with React. If we tried this DOM, and believe me, we did, we’d get the following error: Warning: validateDOMNesting(…): <tbody> cannot appear as a child of <div> Which makes sense, since yeah, that’s pretty gross HTML. I’d also like to note that making a scroll nicely seems nearly impossible. But since we needed to be able to resize columns, and we didn’t want to have to rely on to keep our headers and our cells aligned (because of overall expense), we needed a new solution. We came upon the following solution because although React makes creating invalid impossible, it makes rendering HTML super cheap and efficient: <tbody> JavaScript HTML <div><thead>…headers</thead></table><div style=”overflow-y:auto”><table><thead style=”visbility:hidden;”>…copy of above headers</thead> <tbody><tr></tr>…more rows</tbody></table></div></div> We end up with a lot more DOM here, but we get something pretty powerful as well. Although we have two HTML copies of our Header component, they are actually the exact same React components (so no extra code required) — being driven by the same slice of Redux state (no extra state required). This was incredibly helpful. When one of the visible headers is resized, although it doesn’t update the corresponding cells automatically, it update the Redux store with a new width prop. That width is also driving the invisible header’s width, which then triggers the browser to resize the corresponding <td>’s in the scrollable container. does And , we have two disparate tables communicating via Redux state. We are an action when header actions occur, but we don’t need to keep track of cell width (which would be painful and expensive). Viola dispatching This was one of the first “ah-ha” moments for me, working with React and Redux. I kept running into problems I had solved before with things like jQuery or Angular that React made a little more difficult (like the invalid DOM problem). But when it came to core view-centric problems like having to efficiently update the DOM, or sensibly managing state, React simply made those afterthoughts. I really didn’t need to care at all, so I didn’t. The ‘Making it Fast’ Problem React is fast, but there’s always ways to optimize for speed. Although we went through a phase, where we nailed down each component so they only redrew when needed, I’m going to talk about how we optimized for our problem space. shouldComponentUpdate connect is a decorator exposed by Redux that essentially hooks a component up to the Redux store so that it can read out of the state atom. There is a bunch more to it (that’s incredibly important for performance optimization) but for our purposes, that’s probably enough. The only other thing I’ll say is that we incur a bit more overhead since all connected components are “listening” for state changes, and must run through anytime the store gets updated. Connect mapStateToProps We can see from our final DOM structure, that we’re going to have a bunch of components. The problem that grid poses more than other UI components is scale. For example, in our app we often had instances of thousands of records on a single page, each record with dozens of properties we wanted to display. That’s of DOM, but it’s also a lot of event listeners, and JavaScript objects in memory, etc. a lot We started out by connecting everything — hey, everything needed to read from the store! That meant our header, the scroll-container, the footer, every row, and yes, every single cell. It worked — kind of. Sure it rendered, but interactions were too sluggish and redraws weren’t 60 fps crisp. We needed to do something different. That’s all the details on the problem for now, since I’m going to discuss this in the “Things We Messed Up” section. But I will just say that our final solution (which maybe we should rethink) is to only have a single connected component — the grid container. That way we only run through once, and we pass our props all the way down the chain, letting handle the rest. This resulted is some untenable code at times, but a lightning-quick reconciliation/render cycle. mapStateToProps shouldComponentUpdate The ‘What do we Export’ Problem That brings us to a non-technical problem. At the time of inception, building a “Redux-Component” was a relatively new idea. There were React components that exposed a single export — the component itself. Sometimes they bundle CSS dynamically, and sometimes you needed to import a stylesheet manually. But Redux is a little different because it brings the added dependencies of a store, reducers, and actions. Did these need to be exported? We didn’t know. We guessed they did, but to be honest, we weren’t sure until we started using the component ourselves. We ended up exporting everything — including the demo store. We wanted the grid to run on its own so people could `git clone` and see how it worked themselves, kind of like a UI REPL. But we didn’t want to impose any pattern beyond the simplest usage. It’s via that thinking that we came up the following exports: export const modules = {Actions,Grid,Reducers,applyGridConfig,Store}; It’s obvious to us now that the actions were a necessary export since they turned out to be the public API for the grid — how you communicate information to the component via . We also exposed a number of reducers, each responsible for their own slice of the grid state (i.e. data, columns, editor, pagination). In my mind, this made dealing with grid as heavy or as light as the importing developer wanted. But now I sort of feel like that’s one of the more annoying parts of the component. It makes for cleaner code inside grid, but for a more annoying API. Oh well, so it goes. dispatch We also exported a couple utilities, and this is the area where I think we will spend our near term efforts — building some more utilities that make working with grid a little simpler. We decided to include CSS dynamically at runtime, but to make it optional. By default the CSS will be appended to the document, but can ignored by setting a property via the function. One of the simple joys for me, in this new brave React world, is that components can truly be self-sufficient and sandboxed — it always irked me that I needed to include CSS via <link rel> tags with jQuery components. applyGridConfig Things We Messed Up This section could and should be the longest part of this story. But it’s not going to be, probably out of self-preservation. Using ImmutableJS the Wrong Way This brings us back to . Since we were worried about the connection cost, we simply reduced the number of decorated components we were authoring — to 1. This got us nearly the whole way, except that we saw big lags in performance when the data-set got large (1000+), and that didn’t sit well with us. connect We starting diagnosing the problem using tools and saw that we were spending almost no time in wasted cycles. Here’s the readout from React-Perf: React Perf What, we were only wasting 1.8ms on a grid with 10,000 rows? We weren’t needlessly recalculating props for components, and we weren’t needlessly redrawing either. So what was the problem? We opened up the browser profiler ( is first rate, if you’ve never used it), and we recorded a session where we performed a couple click events. We experienced the heavy lags we were consistently seeing with large data sets, so we went to profile logs to see what was going on. Chrome’s Nearly of the JavaScript runtime was being spent in garbage collection. And even more alarming, nearly of the time was spent in ’ function? For a couple single click events? 25% 8% ImmutableJS toJS When I think about this now, it’s so obvious that this was due to our poor implementation of which involved heavy deserialization of immutable data structures to plain JavaScript objects. However, back then, I remember this blowing my hair back. I remember thinking ‘what the hell kind of memory leak required 15% of our execution memory?’. And ‘what the hell is wrong with toJS?’. Here’s a simplified version of what was going on: mapStateToProps export const mapStateToProps = (state, props) => ({gridData: stateGetter(state, ‘dataSource’, props.stateKey),}); export const stateGetter = (state, key, gridStateKey) => state.getIn([key, gridStateKey]).toJS(); For each property that we cared about, whether it was columns, or data, we were converting our immutable data (which was being stored in our reducers) to plain JavaScript objects in since the innards of grid were operating on native objects instead of immutable ones (some kind of feeble attempt at separation of concerns). mapStateToProps We knew, even then, that was going to be expensive, but what we didn’t know was that runs even before thanks to Redux. So anytime an action fired, we recursively toJS()ed our entire state node for the grid. This explained why we saw the problem grow linearly as the data sets got larger. It also explained the crazy amount of garbage collection, since the execution of didn’t even do anything with the newly created native objects — specifically when an event didn’t require a redraw, those fresh new objects were simply thrown away. toJS mapStateToProps shouldComponentUpdate mapStateToProps The solution was simple after we figured out where and what the problem was. We simply removed the calls and made the innards of grid work with immutable data. This is where we got the biggest performance boost. Since this change, we haven’t run into any real performance snags at all. Looking back now, I think this was my most egregious error, causing me to change the way I thought about open source libraries as a whole (more on that below). toJS Requiring a `store` Prop This has since been remedied, but up until version 5.0.0, a Redux store was one of the required props for grid. It simply wouldn’t run unless the store was explicitly provided. I chalk this one up to not analyzing the landscape as grid matured. We ended up this very easily by simply pulling the store from , the pattern many other popular Redux frameworks had already implemented. solving context Things we Learned Along the Way Maybe this should be the longest section? No probably not, we messed up a lot along the way. Take a look around Although we were venturing out into unknown territory (especially myself), every time we didn’t know the solution to a problem, we were able to peruse other popular GitHub repos to see how something was accomplished, or what pattern was being employed. This is something I wish I would have done at every step of the way. A minute of research can save you weeks of refactoring. Open Source is a lot of work And it’s worth it. But open source projects don’t get awesome until you have a bunch of people all working together. I can’t tell you how exciting it is to have people you don’t know (and without provocation) collaborating on a project. Some of the most creative and sweeping changes come from having a new set of eyes on an old problem. If you don’t want to, or you don’t know where to start, or ask a question. Submit a Pull Request. open an Issue Testing pays dividends Over the course of grid’s lifetime, its undergone 3 heavy refactors. Removing connect, and modifying components to use immutable objects required nearly full rewrites of much of the source. Because we were stalwarts in the beginning about adding tests, and checking coverage, these refactors were made easier, and felt less burdensome. It was a really great feeling completing a refactor and watching your tests pass. Even better, when a couple failed for good reason, corrections were made, and we could feel confident about what we had built. Understand the tools you use I’ve always thought about libraries as black boxes. If I needed a utility/component/thing, and it’s been built before, why recreate the wheel right? Sure, you learn the API and you use the tool to solve the problem at hand. But beyond that, I generally didn’t go look inside to see how that problem is solved. And that bit me here — I had a fundamental misunderstanding of how Immutable worked, and that caused a lot of pain and refactoring. If I’ve learned anything, it’s that before choosing your tools, take a moment to see how they work, if they’re truly right for the job, and you implement them correctly. make sure And Now to the Future Here’s a list of things we’d like to accomplish in the near to long future, in no particular order: * Implement selectors* Addition of new UI plugins (row expansion, etc)* Add more extensibility around filtering data* More fleshed out examples for the demo site* Implement drag and drop for flat data* Better documentation Please open a pull request and accomplish one of these goals! Or come up with a better idea! Or go fix some bugs, or refactor some of the gross away. At the time of writing, grid is at v5.1.8. We’ve come a long way, but we’d like to go a lot further. is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Open Sourcing a Redux Component

Implementing a sample Android Application using MVP , RxJava , Dagger 2 , Retrofit2 , Test , and all the brand new modern methods and libraries Previously on this article… _Implementing a sample Android Application using MVP, RxJava, Dagger 2, Retrofit2, Test, and all the brand new modern…_hackernoon.com Yet another MVP article — Part 2: How Dagger helps with the project Let’s think that you have studied and which means you know everything about modules and structure and also get more familiar with Dagger usage in wiring up layers. part1 part2 the sample project’s MVP now let’s continue… Let’s get into network and API: Almost all mobile application communicate with their services using the internet. is a perfect library contributed by which can always come handy and help you with developing a network layer for your application. Retrofit Jake Wharton Android Long story short, in this project uses an interface called which shows the way to API: Retrofit, MarvelApi Using is really simple, as you can see there is a method located at which needed some parameters to retrieve what you want, which is character data using its name. retrofit RESTful API http://gateway.marvel.com:80/v1/public/characters A good is the one who always read API documents, you can read more about Marvel APIs: developer _The Marvel developer portal gives Marvel fans, partners and other technologists access to an array of powerful APIs…_developer.marvel.com Marvel Developer Portal - Interactive Documentation , and in which MVP layer MarvelApi is located? All networking and databasing stuff happen inside layer. Model This layer only works with data and business logic and Presenter knows how to call or how to prepare data for the View layer. Please stop manipulating data within theModel layer and pass it safe and sound to the Presentation layer, he knows what to do… and more SOLID principle… According to “ ” of SOLID principle “ ”, then and have totally separated tasks to do. Single responsibility One chef can’t run the whole restaurant Model Presentation “One chef can’t run the whole restaurant”, — novoda Can we have a nice log of what we call and what we receive in API response? Why not! The library uses OkHttp library within which is a powerful network library. All magic happens with Interceptors. I will explain one by one and finally show you how to apply them to your OkHttpClient. Retrofit By a little configuration you can ask this library to show you a decent log in logcat which always comes handy: , but don’t forget to disable this logging thing in release version! you can do this by checking variable which generates during application build. BuildConfig.DEBUG How cache API results caused Database to vanish!!! First time I do this inside a news reader application, all database record updating and queries almost killed all team members. Using OkHttp cache feature you can handle header caches and also have an offline file caching which sometimes could be a perfect substitution for Database pain: There are two cache interceptors in this sample, One cache interceptor changes the header of API response and available caching for 2 minutes ( ), which means somehow debouncing user calls from API for 2min. maxAgeMin Another one is the offline interceptor, which uses cache directory (which provide using from module) to save API responses into files for 7 days ( ). Dagger app maxStaleDay Don’t panic if everything is new, you will learn how to use it after some sample project… ;) Do you trust network condition after an API call failure? No, then please retry! Network connections are always lossy or even the service might be down for a few seconds and they may cause trouble for the app, so please try again before informing the user about the situation! I look for retry policies using but none of them works with , but this interceptor works: RxJava Retrofit you can customize it if you require more retry times or even more condition to decide to retry or not, but I think it is fine. :) , and how to attach all interceptors to my OkHttp client? All interceptors are provided inside , which also add them all to OkHttpClient: ClientModule Take care of the statement which comes as the result of variable. if(isDebug) BuildConfig.DEBUG There is also the Network Timeout which tells OkHttp how long wait for the response. …Where is the Retrofit then! Okay, all these codings was for the final step… Inside we use that to create the instance and use it to create : ApiModule OkHttpClient Retrofit MarvelApi You have to provide that usually is the first static part of all your service API URLs, which in this sample is “http://gateway.marvel.com:80/”. (don’t forget the last ‘/’, it is required for the library and may cause exception) BaseUrl Retrofit API provided in this way would be used by which communicates with service. knows how to response using and you can easily capture the result parse it using Gson and use it with other (i.e map, flat map, filter, etc.) to manipulate and prepare a response and hand it to layer to present to the user. SearchInteractorImpl Retrofit RxJava RxJava operators View That’s it for now… Please clone the and get more familiar with it because in next part I will explain more about RxJava and RxAndroid and how it helps with spreading response from to layer. project repo from GitHub core View I look forward to your comments and helping for more improvements with this article. Share this article if you think it is useful, and follow me for more articles . Mohsen Mirhoseini To be continued… _Implementing a sample Android Application using MVP, RxJava, Dagger 2, Retrofit2, Test, and all the brand new modern…_hackernoon.com Yet another MVP article — Part 4: RxJava and RxAndroid know how to response

Yet another MVP article — Part 3: Calling APIs using Retrofit

Implementing a sample Android Application using MVP , RxJava , Dagger 2 , Retrofit2 , Test , and all the brand new modern methods and libraries Previously on this article… _Implementing a sample Android Application using MVP, RxJava, Dagger 2, Retrofit2, Test, and all the brand new modern…_hackernoon.com Yet another MVP article — Part 1: Let’s get to know the project Let’s think that you have studied which means you know everything about ’s modules and . part1 the project structure now let’s continue… Would you explain how Dagger wire up modules and MVP layers in the core? Dagger diagram uses , and to know what and how to dependencies. You can find more articles which explain more about what’s going on inside Dagger. Dagger2 Modules Components, SubComponents inject From Dagger diagram bottom to top I can mention and which provide and : CacheModule SearchModule View Presenter “Trying new shoes doesn’t require you to saw your feet off”!, — Novoda First of all, take care of return types of provide methods, they all return interfaces, not the implementation of that interface! This is how we can replace the implementation for further tests, and also I have to mention that this is a mixture of , and principles of . Open/closed Liskov substitution Dependency inversion SOLID Secondly, do not forget that we are still inside module and we have no idea about how it is gonna be used by . core View Finally, these two modules are being used by and that are ’s SubComponents, which I will explain in module. CacheSubComponent SearchSubComponent ApplicationComponent app We had two more modules inside that help us with providing retrofit dependencies, and Being familiar with will help you with understanding what’s inside, however, I will explain everything about it in next parts of this article. core ApiModule ClientModule . retrofit2 Both of these modules and DatabaseModule are being used by ApplicationComponent which I will explain in module. app ...and what’s going on with Dagger inside module? app The module most important Dagger part is which uses and to provide all the Application injections. app ApplicationComponent AndroidModule ApplicationModule What’s inside ApplicationComponent : 1. AndroidModule : This module provides Application and Application which always comes handy for injection while developing for android to access for instance to or different . Some developers implement this module inside ApplicationModule but I prefer to take it separate for more clearance. Context Resources Services Resources This module would be created in class which extends class: MarvelApplication Application as you might have been mentioned this class is abstract which complete in or buildTypes by implementing method which comes handy for doing things for release version or debug version. debug release initApplication() In this sample I have used debug to plant library for avoiding Timber logs in release version: MarvelApplicationImpl Timber 2. ApplicationModule : Almost all application requirements are being provided in this module, : use BuildConfig.DEBUG boolean variable to check if the running instance of the application is in debug mode and use it for logging network API calls in logcat. isDebug : provide network parameters which being used when creating the OkHttp client for Retrofit. networkTimeoutInSeconds, cacheSize, cacheMaxAge, cacheMaxStale, cacheDir : provide the API’s endpoint for retrofit. endpoint : provide RxAndroid schedulers which I will explain in RxJava part. appScheduler : provide network state for handling offline situations. isConnect 3. , from core ApiModule ClientModule 4. …and DatabaseModule 5. SubComponents: The nice thing about is , you can add SubComponents to your main and use all providers within and add yours. Dagger SubComponent ApplicationComponent In this sample, and add up to and make it more brilliant. SearchSubComponent CacheSubComponent ApplicationComponent let’s take a look… SearchSubComponent and CacheSubComponent: let’s take another look to ApplicationComponent: as you can see we had the methods which helps with injection, but what are those methods?! inject plus First of all, I have to mention that inject and plus is the name!! you can rename it to whatever you like and Dagger take care of input and output of the method to know what’s their use! but please don’t monkey around with the name cause your team member must read this code later… using methods you can ask Dagger to add a to the and do the method inside that plus SubComponent ApplicationComponent inject SubComponent. methods take a and return a using that plus Module SubComponent module. let’s take a closer look: Well well well… where does Dagger integration begin? By a little change in we can ask Android to use MarvelApplication implementations as the start point of our app: manifest and in class we create application component once and use it in and by extending and classes. Both of them are abstract and the method must be implemented inside the Activity or Fragment. MarvelApplication Activities Fragments BaseActivity BaseFragment injectDependencies How to drown yourself inside Dagger?! You can do more Dagger if you like! Take a look at this which explains how to Daggerify everything… I have done it inside this sample project by extending and from module using and module. article SearchModule CacheModule core AppSearchModule AppCacheModule in app This is how the magic happens and that’s it for now… Please clone the and get more familiar with it because in next part I will explain more about retrofit and how it helps with network API calls and caching using it. project repo from GitHub I look forward to your comments and helping for more improvements with this article. Share this article if you think it is useful, and follow me for more articles . Mohsen Mirhoseini To be continued… _Implementing a sample Android Application using MVP, RxJava, Dagger 2, Retrofit2, Test, and all the brand new modern…_hackernoon.com Yet another MVP article — Part 3: Calling APIs using Retrofit

Yet another MVP article — Part 2: How Dagger helps with the project

Hi, I am Amr Hesham a Software Engineer, I am interested in Android and Compiler Development. In my Hacker Noon first article, I wrote about how to use the CodeView library to create a syntax highlighter for programming languages with many extra features like autocomplete, change theme, and syntax in the runtime. You can check out the article . here The first idea is to use it in . So for example like Twitter, you can highlight hashtags, website URLs and you can also highlight emails. This feature can easily be done by using CodeView in just 3 lines of code. content-sharing applications codeview.addSyntaxPattern(Pattern.compile( ), Color.BLUE);
codeview.addSyntaxPattern(Patterns.WEB_URL, Color.BLUE);
codeview.addSyntaxPattern(Patterns.EMAIL_ADDRESS, Color.BLUE); "#[a-zA-z0-9]+" You can also add autocomplete for email providers like .com or .com and the final result will be like this. @gmail @yahoo The second idea is to use CodeView with a searching feature to highlight all matched keywords in the content. You can easily highlight without searching in the positions in all of the content, and add for example some HTML tags or Spans to highlight one word each time a user looks it up. This feature can easily be done using few methods. First, you need to create a Pattern for your search keyword. It can be a normal string or you can enable the user to search with regex, not just string. Pattern keywordPattern = Pattern.compile(keyword); In Kotlin it will be: keywordPattern : Pattern = Pattern.compile(keyword) val Then you need to add this pattern to CodeView with the color you want to highlight with it. codeview.addSyntaxPattern(keywordPattern, Color.BLUE); Then you need to tell CodeView to highlight the new patterns. codeview.reHighlightSyntax(); Once the user changes the search keyword you just need to replace the old pattern with a new one and there are 2 ways to do that. codeview.removeSyntaxPattern(keywordPattern); Or you can remove all the patterns from CodeView. codeview.resetSyntaxPatternList(); Then you need to add the new pattern and highlight it. codeview.addSyntaxPattern(newkeywordPattern, Color.BLUE);
codeview.reHighlightSyntax(); And when you have done it, the final result will look like this. Keep in your mind that CodeView has many features and you can use it in many different ideas. I just gave you 2 examples but there are more and more. You can use it in language apps, for example, an English app and with an error highlighter so you can highlight spelling mistakes, or create a note app with English words on autocomplete… Etc. All you need is to use your imagination and creativity to create great features with CodeView. It’s very easy to use, well documented, and you can find . many examples on Github And I hope you will enjoy creating your editor with CodeView 😋. You can find me on: , , . Github Linkedin Twitter Enjoy Programming 😋 Previously published at https://itnext.io/android-codeview-the-easiest-way-to-highlight-patterns-53702e0e2164

Android CodeView: How To Highlight Text And Where You Can Apply It

Hi I am Amr Hesham a Software Engineer, I am interested in Android Development and Compiler Design 😎 Last month when I was creating programming language compilers and interpreters for practice and implement creative ideas, I got an idea to create an Android Calculator app ( ) based on a scripting language to represent mathematics operations and functions 🤔. MathScript First, I have worked on the language design to be easy to use with helpful error messages and after implementing it, It’s time to work on the Android app so I need to create a Code Editor for this language with some features to be easy to use. I have decided that the code editor should have some features to be cool and easy for everyone for examples, Custom Syntax highlighter for my new scripting language. AutoComplete for language keywords. Error highlighter to highlight errors and warns. Support multi-theme highlighter and can change the theme in runtime. Easy to update the configuration to add any updates for my language. So how should I create this Code Editor? I have started searching for any library that can give me the ability to create this editor. But the problem is that I want a custom needs because it’s my language, not any popular programming language that people supports in their libraries, and the result of my searching is that no library will give me all that i need. So I have thought that I should create my library to solve this problem and make it generic and anyone can customize it for his needs. And I have created CodeView library, and the goal of it is to make it easy for anyone to create custom Code Editor and to be small and not include configuration for every programming or every theme, so the idea is to give you the kernel and you can customize it as you want. It can support any programming language syntax and even you can use it to highlight links, emails, and hashtags like social media editors, you can support auto-complete easily but add your keywords and the library has a default tokenizer and you can change it too 😋, You can support any number of themes and can move between them in the runtime fast and easy, You can support any types of errors highlighter like error, warn, tips…etc, You can implement some cool features that you love for example highlighter TODO, FIX comment like JetBrains editors. It’s very easy to use, well documented, has many examples on Github you can know how to download and use it from the Github link: . CodeView and I hope you will enjoy creating your editor with CodeView 😋. Previously published at https://itnext.io/android-codeview-an-easy-way-to-create-code-editor-app-5d67c3534f84

COREVIEW

coreview.com

-- employees

Since n.d.

COMPANY RANKING

COREVIEW

EVERGREEN INDEX #53

Representing this company? Click here to claim and customize this page!

CoreView WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

COREVIEW

coreview.com

-- employees

Since n.d.

COMPANY RANKING

COREVIEW

EVERGREEN INDEX #53

RELATED COMPANIESRANK

STORIES ABOUT COREVIEW

Representing this company? Click here to claim and customize this page!

CoreView WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!